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SECTION 1 INTRODUCTION 



1.1 Welcome to MOTOTRBO™! 

Improving workforce productivity and operational effectiveness requires superior communications 
quality, reliability, and functionality. MOTOTRBO is the first digital two-way radio system from 
Motorola specifically designed to meet the requirements of professional organizations that need a 
customizable, business critical, private communication solution using licensed spectrum. 
MOTOTRBO combines the best in two-way radio functionality with digital technology to deliver 
increased capacity and spectral efficiency, integrated data applications and enhanced voice 
communications. 

MOTOTRBO is an integrated voice and data system solution comprising of mobile and portable 
radios, audio and energy accessories, repeaters, text messaging and location tracking 
applications, and a third-party application developers program. 




Figure 1-1 MOTOTRBO System 

This system planner will enable the reader to understand the features and capabilities of the 
MOTOTRBO system, and will provide guidance on how to deploy and configure the system and its 
components to take advantage of its advanced capabilities. 

This system planner is divided into 5 sections, with the first being this introduction. Section 2 
provides an overview of system level features. Section 3 describes the system components in 
more detail. Section 4 provides guidance on system design considerations including configuration 
of components. Section 5 provides product sales and support information. 

This system planner is complementary to additional training and documentation including: 

• Radio Customer Programming Software (CPS) and related training 

• System workshop/system service training 

• Product specification sheets 
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1 .2 Software Version 

All the features described in the System Planner are supported by the following software versions: 

• Radios - R02.40.00 and above 

• Repeaters - R02.40.00 and above 
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SECTION 2 SYSTEM FEATURE OVERVIEW 

2.1 MOTOTRBO Digital Radio Technology 

This section provides a brief overview of MOTOTRBO digital radio technology. It addresses two of 
the primary benefits delivered by this technology: spectral efficiency and improved audio 
performance. 

2.1.1 Digital Radio Technology Overview 

The digital radio technologies employed by MOTOTRBO can be summarized as follows: 
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Figure 2-1 MOTOTRBO Digital Radio Technology 
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Figure 2-1 “MOTOTRBO Digital Radio Technology” is broken down into four parts which are 
described in the following subsections. 



2.1 .1 .1 Part One: The Analog to Digital Conversion 



When a radio user presses the Push-To-Talk (PTT) button and begins speaking, his voice is 
received by the radio microphone and converted from an acoustic waveform to an analog 
electrical waveform. This voice waveform is then sampled by an analog to digital converter. In 
typical radio applications, a 16-bit sample is taken every 8 kHz, this produces a 128,000bps (bits 
per second) digital bitstream, which contains far too much information to send over a 12.5 kHz 
radio channel. Therefore some form of compression is required. 

2. 1 . 1 .2 Part Two: The Vocoder and Forward Error Correction (FEC) 



Vocoding (Voice encoding) compresses speech by breaking it into its most important parts and 
encoding them with a small number of bits, while greatly reducing background noise. Vocoding 
compresses the voice bitstream to fit the narrow (for MOTOTRBO) 6.25 kHz equivalent radio 
channel. The MOTOTRBO vocoder is AMBE+2™ which was developed by Digital Voice System, 
Inc. (DVSI), a leader in the vocoding industry. This particular vocoder works by dividing speech 
into short segments, typically 20 to 30 milliseconds in length. Each segment of speech is analyzed, 
and the important parameters such as pitch, level, and frequency response are extracted. These 
parameters are then encoded using a small number of digital bits. The AMBE+2™ vocoder is the 
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first to demonstrate very low bit rates while producing toll-quality speech such as traditionally 
associated with wireline telephone systems. 

Together with the vocoding process, Forward Error Correction (FEC) is also applied. FEC is a 
mathematical checksum technique that enables the receiver to both validate the integrity of a 
received message and determine which, if any, bits have been corrupted. FEC enables the 
receiver to correct bit errors that may have occurred due to radio frequency (RF) channel 
impairment. This effectively rejects noise that can distort an analog signal and by comparison 
enables more consistent audio performance throughout the coverage area. At this stage, the 
vocoder has already compressed the 128,000bps input signal to 3,600bps. 

2.1. 1.3 Part Three: Framing 

In framing, the vocoded speech is formatted for transmission. This includes organizing the voice 
and any embedded signaling information (such as color code, group ID, PTT ID, call type, etc.) 
into packets. These packets form a header and payload type of structure - the header contains the 
call control and ID information, and the payload contains the vocoded speech. This same structure 
can also relay Internet Protocol (IP) data packets - the IP packets are simply an alternative form of 
payload to the MOTOTRBO radio. The header information is repeated periodically throughout the 
transmission, thereby improving the reliability of the signaling information as well as enabling a 
receiving radio to join a call that may already be in progress - we refer to this condition as “late 
entry”. 

2.1. 1.4 Part Four: TDMA Transmission 

Finally, the signal is encoded for a Frequency Modulation (FM) transmission. The bits contained in 
the digital packets are encoded as symbols representing the amplitude and phase of the 
modulated carrier frequency, amplified, and then transmitted. 

TDMA (Time Division Multiple Access) organizes a channel into 2 time slots: a given radio’s 
transmitter is active only for short bursts, which provides longer battery life. By transmitting only on 
their alternating time slots, two calls can share the same channel at the same time without 
interfering with one another, thereby doubling spectrum efficiency. Using TDMA, a radio transmits 
only during its time slot (i.e. it transmits a burst of information, then waits, then transmits the next 
burst of information). 

2. 1 . 1 .5 Standards Compliance 

The digital protocols employed in MOTOTRBO (from vocoding and forward error correction to 
framing, transmission encoding, and transmission via two-slot TDMA) are fully specified by the 
ETSI 1 DMR 2 Tier 2 3 Standard, which is an internationally recognized standard with agreements 
among its supporting members. Although formal interoperability testing and verification processes 
for this standard have yet to fully mature, Motorola anticipates that MOTOTRBO radio systems will 
be interoperable with other solutions that comply to the ETSI DMR Tier 2 standard. 



1. European Telecommunications Standards Institute 

2. Digital Mobile Radio 

3. Tier 2 indicates full power conventional operation in licensed channels for professional and commercial 
users. 
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2. 1 .2 Spectrum Efficiency via Two-Slot TDMA 

2. 1.2.1 Frequencies, Channels, and Requirements for 
Spectrum Efficiency 

A radio communications channel is defined by its carrier frequency, and its bandwidth. The 
spectrum of available carrier frequencies is divided into major bands (such as 800/900 MHz, VHF, 
and UHF), and the majority of licensed channels in use today have a width of12.5 kHz. As the 
airwaves have become increasingly crowded, new standards and technologies that allow more 
radio users to share the available spectrum in any given area are needed. The demand for greater 
spectral efficiency is being driven, in part, by regulatory agencies. In the U.S., for example, the 
Federal Communications Commission (FCC) requires manufacturers to offer only devices that 
operate within 12.5 kHz VHF and UHF channels by 2011. By the year 2013, all VHF and UHF 
users are required to operate in 12.5 kHz channels. 

The next logical step is to further improve the effective capacity of 12.5 kHz channels. While there 
is no current mandate requiring a move to 6.25 kHz, such discussions are on-going at the FCC 
and other agencies. It’s only a matter of time before the ability to carry two voice paths in a single 
12.5 kHz channel, also known as 6.25 kHz equivalent efficiency, becomes a requirement in 800/ 
900 MHz, VHF, and UHF bands. Presently, FCC rules are in place to mandate manufacturers to 
build radios capable of the 6.25 kHz efficiency for 800/900 MHz, VHF, and UHF bands, but the 
enforcement of these rules are put on hold. In the meantime, MOTOTRBO offers a way to divide a 
12.5 kHz channel into two independent time slots, thus achieving 6.25 kHz-equivalent efficiency 
today. 

2. 1.2. 2 Delivering Increased Capacity in Existing 12.5 kHz Channels 

MOTOTRBO uses a two-slot TDMA architecture. This architecture divides the channel into two 
alternating time slots, thereby creating two logical channels on one physical 12.5 kHz channel. 
Each voice call utilizes only one of these logical channels, and each user accesses a time slot as if 
it is an independent channel. A transmitting radio transmits information only during its selected 
slot, and will be idle during the alternate slot. The receiving radio observes the transmissions in 
either time slot, and relies on the signaling information included in each time slot to determine 
which call it was meant to receive. 
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By comparison, analog radios operate on the concept of Frequency Division Multiple Access 
(FDMA). In FDMA, each transmitting radio transmits continuously on a designated channel, and 
the receiving radio receives the relevant transmission by tuning to the desired carrier frequency. 

Today’s Analog MOTOTRBO 




12.5K.Hz channel 



12.5kHz Analog 

- 1 voice for each 12.5kHz channel 
- A single repeater for each channel 




12 -5KHz channel 

12.5kHz TDMA 

- Divides existing channel into two timeslots 

- Delivers twice the capacity through repeater 

- Performance is same or better than 12.5kHz FDMA 

- Single repeater does work of two repeaters 

- Reduces need for combining equipment 

- Enables 40% increase in radio battery life 



Figure 2-2 Comparison between Today’s Analog and MOTOTRBO 



TDMA thereby offers a straightforward method for achieving 6.25 kHz equivalency in 12.5 kHz 
repeater channels - a major benefit for users of increasingly crowded licensed bands. Instead of 
dividing channels into smaller slices of decreased bandwidth - which is what would be required to 
increase spectrum efficiency with FDMA methods, TDMA uses the full 12.5 kHz channel 
bandwidth, but increases efficiency by dividing it into two alternating time slots. Additionally, this 
method preserves the well-known radio frequency (RF) performance characteristics of the 12.5 
kHz signal. From the perspective of RF physics - that is, actual transmitted power and radiated 
emissions - the 12.5 kHz signal of two-slot TDMA occupies the channel, propagates, and 
performs essentially in the same way as today’s 12.5 kHz analog signals. With the added 
advantages of digital technology, TDMA-based radios can work within a single repeater channel to 
provide roughly twice the traffic capacity, while offering RF coverage performance equivalent to, or 
better than, today’s analog radio. 
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2.1 .2.3 Two-Slot TDMA Reduces Infrastructure Equipment 

As we have seen, two-slot TDMA essentially doubles repeater capacity. This means that one 
MOTOTRBO repeater does the work of two analog repeaters (a MOTOTRBO repeater supports 
two calls simultaneously). This saves costs of repeater hardware and maintenance, and also 
saves on the cost and complexity of RF combining equipment necessary in multi-channel 
configurations. Just as importantly, the two-slot TDMA signal fits cleanly into a customer’s existing, 
licensed channels; there is no need to obtain new licenses for the increase in repeater capacity, 
and compared to alternative technologies that may operate on different bandwidths, there is no 
comparative increase in the risk of interference with or from adjacent channels. 
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Figure 2-3 MOTOTRBO Requires Less Combining Equipment 
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2.1 .2.4 Two-Slot TDMA Enables System Flexibility 

The two time slots or logical channels enabled by two-slot TDMA can potentially be used for a 
variety of purposes. Many organizations deploying MOTOTRBO systems can use these slots in 
the following manner: 

• Use both the slots as voice channels. This doubles the voice capacity per licensed 
repeater channel, thereby 

• increasing the number of users the system can accommodate, and 

• increasing the amount of air time the users can consume. 

• Use both slots as data channels. This allows the organizations to fully deploy data 
transactions 

• Use one slot as a voice channel, and the other as a data channel. This is a flexible 
solution, that allows customers to equip their voice users with mobile data, messaging, 
or location tracking capabilities. 

In any of these scenarios, additional benefits are realized within the existing licensed repeater 
channel(s). 






Figure 2-4 Example of Two-Slot TDMA 
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NOTE: When used in direct mode without a repeater, two-slot TDMA systems on a 12.5 kHz 
channel do not deliver 6.25 kHz equivalent efficiency. This is because the repeater is 
necessary to synchronize the time slots to enable independent parties to share them. 
Thus, on a direct or talkaround channel, when one radio begins transmitting, the whole 
12.5 kHz channel is effectively busy, even though the transmitting radio is using only one 
time slot. The alternate time slot is unavailable for another, independent voice call. 
However, the alternate time slot can potentially be utilized as a signaling path. The ETSI 
DMR Tier 2 standard refers to this capability as Reverse Channel signaling, and it is 
envisioned to be used to deliver important future benefits to professional users, such as 
priority call control, remote-control of the transmitting radio, and Emergency Call pre- 
emption. This future capacity for reverse channel signaling is a unique capability of TDMA 
technology and, if supported by your system, may be deployed in both repeater and direct/ 
talkaround configurations. At this time, the MOTOTRBO system does NOT support 
Reverse Channel signaling. 

2.1 .2.5 Two-Slot TDMA System Planning Considerations 

System Planning considerations associated with the increased capacity and the flexibility of the 
MOTOTRBO two-slot TDMA architecture include: 

• Capacity planning: 

• How many voice and data users do you have? 

• What usage profiles are anticipated? 

• How many channels and repeaters are needed? 

These questions are addressed in more detail in “System Design Considerations” on page 277. 

• Fleetmapping: 

• How to map users, voice services and data services such as messaging or location 
tracking to channels. 

Voice and data service capabilities are described in more detail in this module and in “System 
Components and Topologies” on page 185. Fleetmapping considerations are addressed in more 
detail in “System Design Considerations” on page 277, in the MOTOTRBO Systems Training, and 
within the MOTOTRBO radio CPS. 

• Migration Planning: 

• How to migrate existing channels to digital channels? 

• What updates to licensing requirements may be needed? 

These questions are addressed in mode detail in Section 4 “System Design Considerations” on 
page 277. 

2.1.3 Digital Audio Quality and Coverage Performance 

This section describes how digital audio drives coverage performance. It also sets expectations for 
how digital audio behaves and sounds from the end-user’s perspective. 
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2.1 .3.1 Digital Audio Coverage 

The main difference between analog and digital coverage is how the audio quality degrades 
throughout the coverage region. Analog audio degrades linearly throughout the region of 
coverage, while digital audio quality performs more consistently in the same region of coverage. A 
primary reason for the different degradation characteristics is the use of forward error correction 
coding used in digital transmissions, which can accurately deliver both audio and data content with 
virtually no loss over a far greater area. 

It is this error protection that allows a MOTOTRBO system to provide consistent audio quality 
throughout its coverage area. A comparable analog system can never offer such consistency. In 
the MOTOTRBO system, the audio quality remains at a high level, because the error protection 
minimizes the noise effect. 

The figure below graphically illustrates the relationship of delivered system audio quality, while 
comparing good to poor audio quality with strong to weak signal strength. Do note that 

• In very strong signal areas the analog signal, because there is no processing, may 
sound slightly better than the digital audio signal. 

• Digital signals increase the effective coverage area above the minimally acceptable 
audio quality level. 

• Digital signals improve the quality and consistency of the audio throughout the effective 
coverage area. 

• Digital signals do not necessarily increase the total distance that an RF signal 
propagates. 




Figure 2-5 Comparison of Audio Quality versus Signal Strength for Analog and Digital 
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2.1 .3.2 Predicting Digital Audio Coverage 

Predicting coverage for a radio site can be complicated. There are many factors that affect RF 
performance prediction, and generally, the more factors that can be considered, the more accurate 
the prediction of coverage. Perhaps the most influential factor is the selection of the RF 
propagation model and/or RF prediction software tools. 

Coverage prediction techniques for analog and digital systems generally follow the same basic 
procedures, and require similar sets of input factors. Therefore, if the site’s analog coverage 
footprint is already known, it is easier to plan the site’s digital coverage footprint. This approach 
allows the system designer to use their existing analog site coverage prediction techniques, 
whether simple or complex, and then translate the results of the analog coverage prediction to 
predict digital coverage. 

Delivered Audio Quality (DAQ) is a method to quantify audio quality. It is a measure of the 
intelligibility and quality of voice transported through a communications system, as defined in TIA 
TSB-88. DAQ reports audio quality on a 5 point scale, with a DAQ rating of 3 considered as the 
minimal acceptable level of audio quality for public safety applications. The definition of DAQ 3 is 
“Speech understandable with slight effort and occasional repetition required due to Noise/ 
Distortion.”. 

When comparing an analog site and a MOTOTRBO site, the relative regions of coverage offering 
comparable audio quality are illustrated in the figure below. 



Analog Digital 




Improving Audio Quality 

>- 




Figure 2-6 Differences in Analog Coverage 

For a DAQ 3 audio quality, MOTOTRBO provides a greater usable range than analog, when all 
other factors are considered equal (e.g. transmit power level, antenna height, receiver noise 
figures, IF filter bandwidths, no audio processing - such as Hear Clear - on the analog radios, 
terrain, antenna combining equipment, etc.). 
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For an advanced, more comprehensive understanding of RF coverage prediction for the 
MOTOTRBO site, the reader is encouraged to obtain the TIA Telecommunications Service Bulletin 
TSB-88 - “Wireless Communications Systems-Performance in Noise and Interference-Limited 
Situations, Recommended Methods for Technology-Independent Modeling, Simulation, and 
Verification.” 

A copy of TSB-88 can be obtained from http://www.tiaonline.org. 

2.1 .3.3 User Expectations for Digital Audio Performance 

There are a number of differences between how digital audio behaves compared to analog audio 
from the end user (listener’s) perspective. Motorola has found that setting proper end user 
expectations in this regard is an important aspect of system planning. 

What End-Users will Experience with Digital Audio 

• Consistent performance throughout coverage area with no gradual fade at the 
fringes: While analog signals slowly degrade as the receiver moves away from the 
transmitter, digital signals perform more consistently throughout the coverage area. 
However, digital signals, more abruptly, shift from “good” to “no signal”, when crossing 
the fringe of the coverage area. This means, users cannot rely on degrading audio 
quality to warn them that they are approaching the fringe of coverage. On the other 
hand, just prior to the fringe of the coverage area, digital audio is still crisp and clean, 
whereas analog audio has excessive noise and static. 

• Digital Sounds Different: The vocoding process is designed to deliver optimum audio 
quality with a very small number of bits. Some listeners find the resulting tonal qualities 
of digital speech somewhat different from what they have experienced with analog 
speech. Because the vocoding process is highly specialized for reproducing human 
speech, other sounds like music and tones are not reproduced accurately. Additionally, 
digital audio can introduce end-to-end audio delays. When overwhelming errors or 
dropouts are encountered, digital radios can generate some unique-sounding audio 
“artifacts”. 

• Background Noise Reduction: The advanced vocoding capabilities in MOTOTRBO 
also include background noise reduction. Regardless of what is happening in the 
environment of the transmitting radio, only voice is reconstructed at the receiving radio - 
background noise, like machine noise, wind noise, and traffic noise, is not 
reconstructed, and thus, not heard. This is a key advantage of the MOTOTRBO digital 
voice solution over typical analog solutions, because noisy environments like factories, 
stores, work sites, and windy locations do NOT significantly degrade communication 
intelligibility. 

What End-Users will NOT Experience with Digital Audio: 

• Digital radio is not “CD Quality.” MOTOTRBO is the first radio in the industry to use 
the AMBE+2™ low bit rate vocoder to deliver communications grade voice quality. End 
users should not be misled into thinking that “communications grade” digital audio 
quality in radio systems is analogous to the high fidelity audio quality of CD's and DVD's. 

• Digital cannot solve historic problems. System issues with coverage and 
interference are not necessarily eliminated by switching to digital. Adjacent or co- 
channel interference may sound different to a digital user, but digital technology does 
not solve interference issues. For example, analog interference will not be heard as 
voice to a digital radio and vice versa, but disruption of system performance can still 
occur. 
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2. 1.3.4 Audio Balancing 

Transmitting voice over a digital air interface requires a voice coder, or vocoder for short. The 
vocoder used by MOTOTRBO is the Digital Voice Systems Inc. (DVSI) AMBE+2™. This vocoder 
delivers excellent voice quality with robustness to both background noise and RF channel bit 
errors in a 6.25 kHz equivalent channel bandwidth. In order to produce optimal voice quality, the 
input level into the vocoder must fall within a specific amplitude range. 

The diverse nature of users with respect to mouth-to-microphone distance as well as voice level 
and directivity can make this a bit problematic. In an effort to produce optimal voice quality over 
these diverse input conditions, MOTOTRBO digital always employs Automatic Gain Control (AGO) 
in the audio transmit path. The primary function of the transmit AGO is to produce the best voice 
quality possible under real life conditions. Since voice is still the main application of a two-way 
radio, this is a primary goal. 

A secondary result of the AGO is to produce flat received speech loudness level over a range of 
input levels at the microphone. The usage of IMPRES Accessories extends this input range so 
optimal voice quality occurs over an even greater input range. Figure 2-7 “Transmit Audio 
Sensitivity” illustrates this extended range flat response in the curve titled MOTOTRBO with 
IMPRES RSM (Digital). This same response curve can also be produced in analog mode by using 
an IMPRES Accessory and enabling Analog Mic AGO in the CPS General Settings. Figure 2-7 
illustrates this type of response in the curve titled MOTOTRBO with IMPRES RSM (AGO on, 
Analog). An advantage of this type of response is that soft talkers and users that turn away from 
the microphone while speaking will still come through loud and clear. 
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Figure 2-7 Transmit Audio Sensitivity 
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The flat audio response of digital is different from the traditional analog audio response. The 
traditional response is a linear response and the louder one speaks, then the louder the received 
volume. Figure 2-7 illustrates a traditional analog response in the curves titled Professional Series 
and MOTOTRBO with IMPRES RSM (AGC off, Analog). When Analog Mic AGC is disabled, then 
the Analog Mic Gain (dB) is adjustable in the CPS General Settings. Therefore, MOTOTRBO in 
analog mode is able to deliver the traditional analog response and is adjustable to fit into existing 
systems. 

Examination of Figure 2-7 indicates that digital and traditional analog responses are similar at an 
input Sound Pressure Level (SPL) of 98 dB. Below this level, analog is quieter than digital. This is 
important to note as a system requiring MOTOTRBO to function as a digital radio and also as an 
analog radio during migration, may experience received audio level differences that are mode 
dependant. This could occur when scanning both digital and analog channels and the analog 
talker is located in a quiet environment such as an office. In quiet environments many users tend 
to speak softly and therefore the input will fall below the equivalent response level of 98 dB SPL. 
Therefore, during the migration period, the analog response may be quieter than the digital 
response. 

2.2 Basic System Topologies for Digital and Analog 
Operations 

MOTOTRBO is a two-way radio system - conventional and trunked. In its most basic form, a 
MOTOTRBO system is comprised of radios that communicate with each other in the following 
available modes: 

• Direct mode 

• Repeater mode 

• Through a repeater in conventional single site mode 

• Through a set of repeaters in IP Site Connect mode 

• By trunking a set of repeaters in Capacity Plus mode 

• By trunking a set of repeaters connected across multiple sites in Linked Capacity Plus 
mode 

The MOTOTRBO system can be configured to operate in analog mode, digital mode, or in both 
modes. 

2.2.1 Repeater and Direct Mode Configurations 

In direct mode, receive and transmit functions are both carried out on the same physical channel 
(i.e. transmit and receive frequencies are the same). 

I.When operating in Analog Direct Mode, MOTOTRBO supports one voice path (transmit 
and receive) on one physical channel, and can be configured to operate in 1 2.5/20 kHz 
channel bandwidth systems. 

The option board interface meets the timing constraint of the MPT1327 standard, which is 
a signaling standard for trunked private land mobile radio system. The following features 
do not work with MPT1327: 



VOX 
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• Scan (normal and priority) 

• Battery saver 

2. When operating in Digital Direct Mode, MOTOTRBO uses one physical channel 
configured for a 12.5 kHz channel bandwidth. On that one direct 12.5 kHz physical 
channel bandwidth, a MOTOTRBO digital system can support only one voice (or data) 
path at a time. Without a repeater in place to coordinate the time slot sequence among 
radios, only one radio can transmit at a time in order to guarantee transmissions do not 
overlap. 

In repeater-based radio communications systems, a voice path requires a pair of channels: one for 
transmission, the other for reception. 

2. 2. 1.1 Analog Repeater Mode 

When operating in Analog Repeater Mode, MOTOTRBO operates similar to existing analog 
repeaters by supporting one voice path (transmit and receive) on one pair of physical channels, 
and can be configured to operate in 1 2.5/20 kHz channel bandwidth systems. 

2. 2. 1.2 Digital Repeater Mode 

When operating in Digital Repeater Mode, MOTOTRBO uses a pair of physical channels 
configured for 12.5 kHz channel bandwidth. Through the use of Time Division Multiple Access 
(TDMA) technology and the synchronization provided by the repeater, MOTOTRBO splits each 
12.5 kHz channel (one transmit and one receive) into two independent time slots or logical 
channels within the 12.5 kHz physical channel bandwidth. This allows the user to assign voice or 
data traffic to either of the time slots independently. To the end user, this means they now have two 
voice or data channels that can be managed independently, instead of one. These two logical 
channels (two time slots) can transmit and receive independently of each other. The two logical 
channels in a 12.5 kHz channel makes the channel equivalent to a 6.25 kHz wide channel. 

2. 2. 1.3 Dynamic Mixed Mode 

When operating in Dynamic Mixed Mode (DMM), MOTOTRBO uses a pair of physical channels 
configured for 12.5 kHz channel bandwidth for digital operation and analog operation. The 
repeater dynamically switches between analog and digital modes based on the call it receives 
from radios. If an analog radio transmits, the repeater switches to analog mode to repeat the 
analog call. However, the repeater only repeats analog calls that are qualified by PL (DPL/TPL). If 
a digital radio transmits, then the repeater switches to digital mode to repeat the digital call if the 
call uses the right color code. While the repeater repeats one analog call at a time, it can repeat 2 
digital calls at a time, one on each logical channel. 

When a repeater repeats a new digital call that starts on one of the logical channels, the repeater 
does not qualify any analog call including an Emergency Call until the digital call (both the 
transmission and call hang time) is over and the corresponding channel hang time has expired. 
Upon the expiry of channel hang time, only then does the repeater start qualifying both analog and 
digital calls simultaneously. Similarly, if an analog call is being repeated, the repeater does not 
qualify any digital call including digital data and Emergency Calls on any of the two logical 
channels until the analog call is over and the corresponding hang time has expired. 

Analog console device(s) are supported only when the repeater has not qualified an OTA digital 
call. If an analog console device tries to key up the repeater when a digital call has been received 





16 



System Feature Overview 



over-the-air, the analog call will be denied access. The repeater notifies the console via a channel 
busy tone generated over the speaker and Rx audio pins on the 4-wire repeater interface. Analog 
consoles do not have priority over digital calls (voice or data) in DMM mode. 

Dynamic Mixed Mode is a repeater only configuration and the main functions of this feature are: 

• The system requires one pair of physical channels (one Tx frequency and one Rx 
frequency) for both analog and digital calls, one MOTOTRBO repeater, and one set of 
RF equipment (antenna, combiners, couplers, LNA, etc) to enable analog and digital 
radio users to communicate. 

• This configuration allows the user to have a mix of legacy analog radios and the digital 
MOTOTRBO radios in a MOTOTRBO system. 

• The repeater supports two independent time slots or logical channels within the 12.5 
kHz physical channel bandwidth while repeating digital calls. However, the repeater 
supports one voice path (transmit and receive) on a 12.5 kHz channel while repeating 
analog calls. 

Dynamic Mixed Mode does not support the following configurations/features. 

• IP Site Connect configuration - This means that in Dynamic Mixed Mode, the 
repeater can only repeat the digital calls over-the-air and cannot send the voice/ 
data packets over the IP network. The status of the repeater and the control of the 
repeater cannot be performed from a remote PC application like RDAC-IP. 

• Capacity Plus configuration - This means that in Dynamic Mixed Mode, trunking 
the logical channels of multiple MOTOTRBO repeaters as per Capacity Plus is not 
supported. 

• FCC Type-1 and Type-ll monitoring - Since FCC Type-1 and Type-ll monitoring are 
not supported in single site analog operation in any of the earlier MOTOTRBO 
releases, it is also not supported in Dynamic Mixed Mode single site operation. 

• Transmit Interrupt feature - The Voice Interrupt, Emergency Voice Interrupt, 
Remote Voice Dekey, and Data Over Voice Interrupt features are presently not 
supported in Dynamic Mixed Mode systems. 

• RDAC over IP feature - RDAC over local USB and connections via GPIO are 
supported. RDAC over the network is NOT supported. 

• Repeater Knockdown - In Dynamic Mixed Mode systems, this feature is not 
supported during an ongoing digital transmission. 

• PTT on a 4-wire interface - In Dynamic Mixed Mode systems, this feature is not 
supported during a digital repeat operation. 

2. 2. 1.4 IP Site Connect Mode 

When operating in IP Site Connect Mode, MOTOTRBO combines the logical channels of multiple 
MOTOTRBO systems (operating in digital repeater mode at dispersed locations) into one logical 
channel covering all locations. In this mode, repeaters across dispersed locations exchange voice 
and data packets over an IPv4-based back-end network. There are three main functions of this 
mode. 
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• To increase the RF coverage area of a MOTOTRBO system. 

• To provide voice and data communication between two or more MOTOTRBO single 
site systems located at geographically separate locations. 

• To provide voice and data communication between two or more MOTOTRBO single 
site systems operating in different frequency bands (e.g. 800/900 MHz, VHF, and 
UHF). 

The backend network of an IP Site Connect system is designed to work seamlessly with internet 
connectivity provided by an Internet Service Provider (ISP). The system only requires that one of 
the repeaters have a static IPv4 address, while the others may be dynamic. Also, the system 
avoids the need for reconfiguration of a customer’s network such as reprogramming of firewalls. 

When a new call starts at one of the logical channel of a repeater, the repeater sends the call to all 
the repeaters and all these repeaters repeat the call on their corresponding logical channel. This 
allows a radio in the coverage area of any repeater to participate in the call. Thus, the coverage 
area of an IP Site Connect system is the sum of the coverage areas of all the repeaters. However, 
note that an IP Site Connect configuration does not increase the capacity (i.e. number of calls per 
hour) of the system. The capacity of one Wide Area Channel of an IP Site Connect system is 
approximately the same as that of a single repeater working in digital repeater mode. 

In an IP Site Connect configuration, MOTOTRBO radios support all the features that they already 
support in digital repeater mode. This also includes Transmit Interrupt features that are supported 
on logical channels configured over wide area networks. Additionally, the radios are capable of 
automatically roaming from one site to another. 

The IP Site Connect configuration of MOTOTRBO does not require any new hardware besides 
backend network devices such as routers. If a customer has multiple MOTOTRBO systems 
working in digital repeater mode at dispersed sites and wants to convert them into an IP Site 
Connect system then the repeaters and the radios should be updated with new software and the 
repeaters need to be connected to an IPv4-based backend network. It is possible to configure a 
repeater such that 

• Both logical channels work in IP Site Connect mode (i.e. over wide area). 

• Both logical channels work in digital repeater mode (i.e. single site over local area). 

• One of its logical channels works in IP Site Connect mode (i.e. over wide area) and 
the other logical channel works in digital repeater mode (i.e. single site over local 
area). 

MOTOTRBO has three security features in the IP Site Connect configuration. 

• Provides the confidentiality of voice and data payloads by extending the privacy 
feature, whether Basic or Enhanced, to cover the communication over the backend 
network. 

• Ensures that all the messages between repeaters are authentic. 

• Supports Secure VPN (Virtual Private Network) based communication between the 
repeaters for customers needing higher level of security (protection against replay 
attack). 

The IP Site Connect configuration of MOTOTRBO provides a mechanism and a tool to remotely 
manage repeaters. The tool (called RDAC) receives alarms from all the repeaters, helps in 
diagnosis of repeaters, and provides some controls over the repeaters. 
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2. 2. 1.5 Capacity Plus Mode 

When operating in Capacity Plus Mode, MOTOTRBO trunks the logical channels of multiple 
MOTOTRBO repeaters (operating in digital repeater mode) at the same location. This allows the 
radios to share the logical channels, resulting in less waiting time to access the system and 
increased channel capacity for a given quality of service. Another advantage is that the probability 
of all channels being busy at the same instant is low, therefore the probability of a call being 
blocked is lower than when only one channel can be accessed. 

Capacity Plus is a single site trunking configuration of the MOTOTRBO system. In a Capacity Plus 
configuration, all the “idle” radios (i.e. radios neither receiving nor transmitting) are on an idle 
channel called the Rest Channel. Therefore, a new call always starts on the Rest Channel. At the 
start of a call, the Rest Channel repeater selects one of the idle channels as the new Rest 
Channel, informs the radios on the current Rest Channel about the new Rest Channel, converts 
the current Rest Channel to a traffic channel, and starts repeating the bursts sent by the radio. The 
radios that are not participating in the call (i.e. destination of the call is not of their interest) move to 
the new Rest Channel. 

If the current Rest Channel is the last idle channel (i.e. all the other available channels are in use), 
the current Rest Channel remains as the Rest Channel. The call starts on the channel and non- 
participating radios stay on the channel. In this condition, non-participating radios indicate that the 
channel is busy via its yellow LED. If all channels are busy and a radio user initiates a call, then the 
radio generates a distinct tone to indicate that the system is busy. As soon as a channel becomes 
free in the Capacity Plus system, the non-participating radios are informed, and move to the free 
channel. 

At the end of the call (i.e. after the call hang time), the repeater also broadcasts the status of all 
other available channels. This triggers any radio on the channel to move to the current Rest 
Channel or to a channel where a Group Call of interest is active. 

The Capacity Plus system has no central controller to manage the Rest Channel. The Rest 
Channel is managed collectively by all the trunked repeaters. A trunked repeater periodically 
informs the status of its channels to other trunked repeaters whenever the status of its channels 
change. When a new Rest Channel is selected, the selecting repeater informs all the other 
repeaters. The new Rest Channel is selected based on the following conditions: 

• At the start of a call, the repeater of the current Rest Channel selects the new Rest 
Channel. 

• On detection of interference or before starting CWID (i.e. BSI) transmission, the 
repeater of the current Rest Channel selects the new Rest Channel. 

• On detection of no Rest Channel (in the event of a failure of the current Rest Channel 
repeater or the backend network), the repeater with the lowest ID selects the new 
Rest Channel. 

• When a call ends on a system, if a call is in progress on the current Rest Channel, 
then the repeater of the current Rest Channel selects the new Rest Channel. 

The Capacity Plus system does not require an exclusive control channel. The Rest Channel 
changes on every call; in case of an interference or if the repeater becomes unavailable due to 
failure. This results in the following advantages: 

• Non-exclusive channels make it easier to satisfy regulator frequency coordination 
(where exclusive use of channels is not possible). 
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• Capacity Plus does not use “request and grant” mechanism to allocate channels and 
does not require any central controller to trunk the channels. 

• The dynamic Rest Channel mechanism makes Capacity Plus very suitable for an 
environment where channels are shared by multiple radio systems. 

• The dynamic Rest Channel mechanism also improves the reliability of the Capacity 
Plus system. In the event of a repeater failure, the other available repeaters 
automatically reconfigure themselves and continue to work as the Capacity Plus 
system. 

The Capacity Plus system configuration of MOTOTRBO does not require any new hardware apart 
from backend network devices such as routers. If a customer has multiple MOTOTRBO systems 
working in digital repeater mode at the same site and wants to convert to a Capacity Plus system, 
then the repeaters and radios should be updated with the new software, and the repeaters need to 
be connected to an IPv4-based backend network. If one logical channel of a repeater is configured 
to the Capacity Plus mode, then the other logical channel will also be in the same mode. 

In a Capacity Plus configuration, MOTOTRBO systems support all previous digital repeater mode 
features, with the exception of the following: 

• Scan: Capacity Plus supports Group Scan, so a properly programmed radio listens for 
multiple talkgroups within a single Capacity Plus system, but does not support scanning 
channels of another system. Adding multiple talkgroups to the Receive list of a radio 
allows the user to hear the conversations of those talkgroups, and reply within the call 
hang time, regardless of the physical channel on which that call takes place. 

• Emergency Revert Channel: Capacity Plus does not support a revert channel for 
emergency because probability of all Trunked Channels becoming busy is low. 
However, reverting to an emergency group is supported. This promotes a centralized 
handling of an emergency situation. 

• IP Site Connect configuration: Capacity Plus is a single site system and therefore 
does not support features related to IP Site Connect configuration such as wide-area 
coverage and automatic roaming. However, a radio can be programmed with multiple 
channels in multiple zones, one of which could be a Capacity Plus system, another an 
IP Site Connect System, and others could be MOTOTRBO conventional channels or 
Analog conventional channels. 

• Impolite calls: Capacity Plus supports impolite Emergency Call and impolite 
transmissions (i.e. Group members can transmit over an ongoing call). A new call 
always starts on an idle channel and therefore, a radio does not start a non-Emergency 
Call impolitely. 

• Talkaround mode: A radio can have a talkaround personality but in Capacity Plus 
mode, there is no talkaround option. 

• Monitoring of channels status: Monitoring is important in a conventional system, 
where a radio stays on a channel. In Capacity Plus, a radio moves from one Rest 
Channel to another. Most of the Rest Channels are in an idle state and therefore, 
monitoring is not necessarily needed. 

• Fragmentation of a Data Packet: Capacity Plus does not fragment a data packet 
before transmitting over-the-air. Thus, the size of an IP datagram (including IP and UDP 
headers) should be less than the maximum size of the Packet Data Unit. The value of 
the Packet Data Unit is a CPS programmable parameter with a maximum size of 1500 
bytes. 

• Option Board: If the Option Board feature is enabled for Capacity Plus, then the feature 
is automatically enabled for all trunked and revert channels of a Capacity Plus system. 
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On a Capacity Plus personality, the Option Board is not aware of the transmit or receive 
channel. Additionally, an Option Board does not use or create Virtual Personalities in a 
Capacity Plus system. Hence, an Option Board will not be able to customize the current 
working personality. 

• Transmit Interrupt: The Voice Interrupt, Emergency Voice Interrupt, Remote Voice 
Dekey, and Data Over Voice Interrupt features are supported on Capacity Plus systems. 

Capacity Plus does not provide the following features: 

• Coverage of multiple sites, 

• Call queuing, priority, and preemption, 

• Priority Monitor: Capacity Plus provides higher priority only to an All Call, 

• Radio access control. 

Greater detail on system services available in direct-mode and repeater-based system topologies 
is described in “System Components and Topologies” on page 185. 

2. 2. 1.6 Linked Capacity Plus Mode 

When operating in Linked Capacity Plus Mode, MOTOTRBO trunks the logical channels (that is, 
the TDMA slots) of multiple MOTOTRBO repeaters (operating in digital repeater mode) at multiple 
locations and combines the logical channels into one logical channel. This allows radios to share 
the logical channels, as well as increase the RF coverage area of a MOTOTRBO system. 

Linked Capacity Plus (LCP) is a trunked multisite multi-channel configuration of MOTOTRBO, 
which combines both the Capacity Plus and IP Site Connect configurations. This combined 
configuration requires only software updates for radios and repeaters, but does not require any 
new hardware. 

NOTE: Only repeaters with 32 MB of internal memory (e.g. XPR 8380/XPR 8400 or MTR3000) 
can support the LCP configuration. 

Linked Capacity Plus uses the IP Site Connect type of backend network for communication 
between sites. The IP Site Connect supports a wide variety of backend networks from a dedicated 
network to an internet provided by the ISP. Linked Capacity Plus supports all backend networks 
supported by IP Site Connect, but more bandwidth is required from an ISP provider for a LCP 
system, compared to an IP Site Connect system. The backend is designed to work seamlessly 
with internet connectivity. The system requires only one of the repeaters to have a static IPv4 
address. Additionally, the system avoids the need for reconfiguration of a customer’s network, 
such as reprogramming of firewalls. 

Similar to Capacity Plus, LCP repeaters at a site are connected over a LAN. A Capacity Plus 
repeater uses multiple individual messages to communicate with the rest of the repeaters on site. 
However, an LCP repeater sends a broadcast message to IP Limited Broadcast Address 
(255.255.255.255). The broadcast messages may produce some adverse effects on the other 
devices present on the LAN. Therefore, an LCP configuration requires only the LCP repeaters to 
be present on the LAN. 

The call start-up of LCP is a combination of IP Site Connect and Capacity Plus configurations with 
the following enhancements: 
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• In an IP Site Connect system, a customer can configure a logical channel as either a 
local channel or a wide area channel. A call over a local channel is repeated only over 
the local site, whereas a call over a wide area channel is repeated over all the sites 
where at least a channel is idle. Instead of local and wide area channels of IP Site 
Connect, LCP supports both local and wide area talkgroups. A repeater handles a local 
talkgroup call in the same method as in a Capacity Plus configuration. However, a wide 
area talkgroup call is repeated over all the associated sites where at least one logical 
channel is idle. 

• In an IP Site Connect system, a call starts at all sites. This is often called “All sites light- 
up”. An advantage of this is the simplicity in implementation because repeaters are not 
required to know the list of radios present at its site. A disadvantage is that a multi-site 
configuration does not increase the capacity of a system. Only the coverage of the 
system increases. LCP makes the following enhancements: 

LCP allows defining a talkgroup as a wide area talkgroup. A wide area talkgroup call 
lights up only the sites which are statically associated with the talkgroup. The call is 
rejected when a radio tries to initiate a wide area Group Call from a site not associated 
with the talkgroup. 

The talkgroups not defined as wide-area are local talkgroups. A local call ‘lights-up’ 
only one site where the initiating radio is located. 

The LCP Private Call initially “lights-up” all the sites but after approximately 400 
milliseconds, the call continues only at the sites (at most two) where the source radio 
or destination radio are present. 

• In LCP, a wide area non-Emergency talkgroup call starts only if all the associated sites 
have idle channels. This is defined as “All Start.” Additionally, LCP allows a customer to 
reserve a number of logical channels for wide area talkgroup calls only. This improves 
the success of “All Start” for the wide area talkgroup calls. 

• Just like a Capacity Plus system, an LCP system has no controller. Repeaters of a site 
trunk the logical channels available at the site. The trunking process in LCP is similar to 
that of Capacity Plus. Repeaters of a site do not participate in trunking the RF resources 
of another site. Each site trunks their channels independently. 

2.2.2 MOTOTRBO Supports Analog and Digital Operation 

The MOTOTRBO system can be configured to operate in analog mode, digital mode, or in 
Dynamic Mixed Mode. The system can consist of multiple repeaters. A single MOTOTRBO 
repeater configured to operate in Dynamic Mixed Mode can dynamically switch between analog 
and digital modes depending on the type of call it receives. A repeater in Dynamic Mixed Mode 
system cannot be part of multiple repeater system in which the repeaters are connected over the 
network for IP Site Connect, Capacity Plus, or Linked Capacity Plus operation. 

MOTOTRBO portable and mobile radios can communicate in analog and digital. The mobile or 
portable radio user selects the mode of operation (analog or digital), and physical and logical 
channel using his channel selector knob (each channel selection position is configured for a 
particular call type on either a digital channel that specifies both frequency and time slot, or an 
analog channel that specifies both frequency and 25 kHz or 12.5 kHz bandwidth). Radio channels 
are either analog or digital. This is configured by the CPS. The radio can scan between analog and 
digital channels. 

Greater detail on channel planning and configuration is provided in “System Design 
Considerations” on page 277. 
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2.2.3 MOTOTRBO Channel Access 

Channel access dictates what conditions a radio is allowed to initiate a transmission on a channel. 
The channel access rules of MOTOTRBO are governed by the mobile and portable radios. It is the 
radio’s responsibility to assess the state of the system, and utilize its channel access rules to 
decide whether to grant the call to the user. 

In repeater systems, it is the repeater’s responsibility to: 

• Identify if a channel is busy, or 

• Identify if a channel is idle, or 

• Inform for which radio the channel is reserved. 

The repeater does not block or deny any channel access from radios on its system, but will not 
repeat transmissions from another system. 

There are two main types of channel access in a MOTOTRBO system: Polite and Impolite access. 
In the configuration software, channel access is referred to as the Admit Criteria. MOTOTRBO 
supports the following Admit Criteria: 

• Always: This criteria is often referred to as “Impolite” channel access, and can be 
applied to analog and digital channels. 

• Channel Free: This criteria is often referred to as “Polite to All”, and can be applied to 
analog and digital channels. 

• Color Code Free: This criteria is sometimes referred to as “Polite to Own Color Code” 
or “Polite to Own System”, and is applied only to digital channels. 

• Correct PL: This criteria is sometimes referred to as “Polite to Other System”, and is 
applied only to analog channels. The radio checks for a PL match prior to allowing a 
transmission. 

Channel access methods must be specified for each channel in the radio CPS. The TX (Transmit) 
parameters for each defined channel contains an “Admit Criteria” selection that must be set to one 
of the values described above. 

All these channel access options govern how standard group voice calls and Private Calls access 
the system. Not all transmission types utilize these settings. For example, emergency voice calls 
always operate impolitely. This gives emergency voice calls a slightly higher priority over existing 
traffic on the channel. Data calls are always polite. Since a data call can be queued and retried, its 
priority is considered lower than voice. 

Note that a “polite” radio user attempting a voice call will be polite to data, but an impolite user may 
not. Control messages (used for signaling features) are also always polite. The exception is the 
emergency alarm. Emergency alarms are sent with a mix of impolite and polite channel access, in 
order to optimize the likelihood of successful transmission. 

When the Admit Criteria is either Channel Free or Correct PL, a configurable RSSI threshold is 
provided per channel in the radio. If the received signal strength is less than the configured RSSI 
threshold, the signal is considered as an interference and the radio gets channel access when the 
user initiates a new call. However, if the received signal strength is greater or equal to the 
configured threshold, the channel is considered busy and the radio does not get channel access 
when the user initiates a new call. It is the responsibility of the site planner or the service provider 
to set the RSSI Threshold to an appropriate value considering the RF interference and also ensure 
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that the desired signal strength is more than the configured threshold. The default value of RSSI 
Threshold is -124 dBm. The configurable range is between -124 dBm to -80 dBm. When a value of 
-124 dBm is selected, subscriber does not get channel access if carrier activity is detected due to 
interference on the channel when the user initiates a new call. A value of -124 dBm is very 
sensitive to RF interference. 

When operating in IP Site Connect mode, the repeaters also check the channel for interference 
before transmitting. This is required since even though the source radio checks the channel at one 
site, it does not mean there is no interference at another site. Therefore, a repeater will check for 
over-the-air interference before waking up and transmitting. The repeater always acts with an 
Admit Criteria of Channel Free and has a configurable signal strength threshold. Note that 
although one site may be busy, the other non-busy sites will continue with the call. 

2.2.3. 1 Impolite Operation (Admit Criteria of “Always”) 

When configured for impolite operation, a radio does not check for an idle channel prior to allowing 
a transmission. From the user’s perspective, the radio simply transmits when the PTT is pressed. 
However, on a digital repeater channel, the radio checks if the repeater is hibernating. 
Transmission will not proceed, if the repeater is hibernating and the radio is unable to wake it. 

NOTE: It is very important to note that when a radio is utilizing impolite operation, it is possible that 
it is transmitting on top of another user’s transmission. This causes RF contention at the 
target. When RF contention occurs between digital transmissions, it is impossible to 
predict which signal is usable. If one transmission is much stronger than the other, it is 
received instead of the weaker signal. But in most cases, the two transmissions on the 
same frequency and time slot results in both transmissions being unusable. Thus, it is 
recommended that only disciplined users are granted the right to use impolite operation. 
Further, those impolite users are encouraged to utilize the busy channel LED on their radio 
to determine, if the channel is idle prior to transmitting. 

When operating in IP Site Connect mode, it is important to understand that impolite channel 
access only occurs at the local site. If a call is taking place on the IP Site Connect system, and the 
original source of that call is at the same site as the interrupting “impolite” radio, RF contention will 
occur and it is unclear which source will be successful. If the original source of the call is at a 
different site from the interrupting radio, the original call continues at all other sites except where 
the interrupting radio is located. 

When operating in Capacity Plus or Linked Capacity Plus modes, the impolite operation is 
supported only in Emergency Calls. 

2. 2. 3. 2 Polite to All Operation (Admit Criteria of “Channel Free”) 

When configured for Polite to All operation, the radio checks if channels are idle or busy, prior to 
allowing a transmission. The radio is polite to all analog or digital transmissions, another system’s 
transmission, or other traffic on your system. This option is often used, when there are neighboring 
communications systems, to prevent radio users from disrupting each other’s transmissions. 
However, when this option is used, any strong signal on the channel blocks other users from 
transmitting. 
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2. 2. 3. 3 Polite to Own Digital System Operation 
(Admit Criteria of “Color Code Free”) 

This criteria applies only to digital channels. When configured for Polite to Own Digital System 
operation, the radio checks for an idle or busy channel, prior to allowing a transmission. This 
operation is similar to the Polite to All operation with exception that the radio is not polite to analog 
systems or other system’s transmissions. It is only polite to other traffic in its own system. This 
option is often used when there are no neighboring communications systems, or when there is no 
concern about interfering with radios in neighboring communication systems. 

2. 2. 3.4 Polite to Other Analog System Operation 
(Admit Criteria of “Correct PL”) 

This criteria applies only to analog channels. When configured for Polite to Other Analog System 
operation, the radio checks for an Idle or busy channel, prior to allowing a transmission. This 
operation is similar to the Polite to All operation with exception that the radio is not polite to analog 
systems with the same PL. It is polite to other system’s transmissions. The radio checks for a PL 
match prior to allowing a transmission. 

2. 2. 3. 5 Polite or Impolite, or Voice Interrupt While Participating 
in a Call (In Call Criteria) 

The In Call Criteria applies only when the radio is participating in an active call. The radio can 
optionally allow others that are part of the call to transmit impolitely (Always), to automatically clear 
the channel using the Voice Interrupt feature prior to beginning the voice transmission (Voice 
Interrupt), or to follow the previously configured channel access (Follow Admit Criteria). If 
configured for an In Call Criteria of Always, the user will receive a Talk Permit Tone when they 
press the PTT while receiving a transmission for them. In other words, a radio has the ability to 
transmit over another user while listening to their transmission. However, when this happens, the 
other party does not stop transmitting and therefore RF contention can occur which may corrupt 
both transmissions. The In Call Criteria of Voice Interrupt is an alternative to the In Call Criteria of 
Impolite. 

The Voice Interrupt option has advantages including the ability to avoid the previously described 
RF contention issue by clearing the channel prior to beginning a transmission, which yields a 
higher probability of successfully communicating with the intended target radio(s), as compared 
with the RF contention encountered with impolite transmissions. However, Voice Interrupt has 
disadvantages including a longer channel access time when an interruption is necessary, due to 
the signaling having to complete the interruption and handoff. 

If configured for an In Call Criteria of Voice Interrupt, the radio user receives a Talk Permit Tone 
when PTT is pressed while receiving an interruptible voice transmission and the channel is 
successfully cleared down. In other words, a radio user has the ability to clear the channel of 
another user’s interruptible voice transmission before beginning their own voice transmission 
when both radios are participating in the same voice call (e.g., both are members of the same 
group during a Group Call, or both are participating in the same Private Call). Depending on the 
radio’s CPS configuration, the radio user whose transmission was interrupted may or may not 
receive a Talk Prohibit Tone until the user releases the PTT. If the channel is not successfully 
cleared down, the user typically receives a Channel Busy Tone until the PTT is released. 
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NOTE: For the Voice Interrupt feature to operate consistently, all radios using the channel should 
be provisioned with the ability to be interrupted. However, not all need to be provisioned 
with the Voice Interrupt capability. 

If some radios are provisioned without the ability to be interrupted (e.g., normally desirable for a 
supervisor’s radio), then those transmissions cannot be interrupted and the radio user receives a 
Channel Busy tone if the Voice Interrupt feature is attempted while receiving an uninterruptible 
voice transmission. 

If configured for Follow Admit Criteria and the previously configured channel access (Admit 
Criteria) is set to either Channel Free or Color Code Free, the user will receive a Transmit Denial 
Tone when they press the PTT while receiving a transmission for them. Users must wait until the 
user stops transmitting and call hangtime starts before they are granted a transmission. Utilizing 
the Channel Free Tone helps train users from transmitting too early. Although a setting of Always 
may be useful for speeding up conversations for well disciplined users, it may cause undisciplined 
users to “step over” other users. Therefore, it is recommended that most users are provisioned 
with an In Call Criteria of Follow Admit Criteria. 

2 . 2 . 3. 6 Repeater Wake-up Provisioning 

When there is no inbound traffic for a specified duration (Subscriber Inactivity Timer), the repeater 
stops transmitting and enters an inactive state. In this inactive state, the repeater is not 
transmitting, but instead it is listening for transmissions. When the user or radio needs to transmit 
through the repeater, the radio sends a wake-up message to the repeater. 

Upon receiving the wake-up message, the repeater activates and begins transmitting idle 
messages. The radio then synchronizes with the repeater before it begins its transmission. 

The repeater wake-up sequence is configurable within the radio. The number of wake-up attempts 
(“TX Wakeup Message Limit") and the time between the attempts (“TX Sync Wakeup Time Out 
Timer”) may be altered if required to operate with other vendor’s systems. It is recommended that 
these values remain at default while operating on MOTOTRBO systems. 
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2.3 MOTOTRBO Digital Features 

2.3.1 Digital Voice Features 

WARNING: It is not recommended to delete a contact from the digital contact list because each 
contact can be tied to a cross-functional fleet of systems and devices communicating 
together. This may cause the radio to work incorrectly. 

2. 3. 1.1 Group Calls 

The digital group is a way of enabling groups to share a channel without distracting and disrupting 
one another. Because two-way radios are well suited for “one-to-many” types of calls, the Group 
Call is the most common call in a MOTOTRBO system. Hence, the majority of conversations takes 
place within a group. 

The Capacity Plus and Linked Capacity Plus systems allow a radio user to leave a Group Call and 
start another voice or emergency or control call (e.g. Call Alert, Radio Check, Radio Inhibit/ 
Uninhibit, etc.) while the radio is busy listening in to a Group Call. The radio moves to the current 
Rest Channel and starts a new call on the Rest Channel. If a user starts a non-Emergency Call 
when all channels are busy, then the call fails, and the radio stays on the traffic channel. 

Individual radios that need to communicate with one another are grouped together, and configured 
to be members of a group. A transmitting radio can be heard by all the radios within the same 
group, and on the same logical channel (frequency and time slot.) Two radios cannot hear each 
other, if they are on the same logical channel (frequency and time slot) but on different groups. 
Two radios on different logical channels cannot hear each other, even if they are placed in the 
same group. 

In MOTOTRBO systems, capabilities for Group Calls are configured with the portable and mobile 
radio CPS. The repeater does not require any specific configuration for groups. Radios can be 
configured to enable the user to select among multiple groups using the radio channel selector 
knob or buttons, or using the radio menu contacts list. Which group a radio user hears on a given 
channel depends on a configurable parameter called the RX Group List. A call preceding tone can 
be provisioned to alert the target user of the incoming Group Call. This can be enabled or disabled 
per Group. An introduction to configuring Group Calls and RX Group Lists is provided in “System 
Design Considerations” on page 277 of this document. 

Groups are defined according to the organizational structure of the end user. When planning for 
groups, customers should think about: 

• which members of the functional workgroups in their organization that need to talk with 
one another, 

• how those workgroups interact with members of other workgroups, and 

• how users will collectively share the channel resources. 

Greater detail on the fleetmapping process is provided in “System Design Considerations” on 
page 277 of this document. 
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2. 3. 1.2 Private Calls 

MOTOTRBO provides the capability for a user to place a Private Call directly to another radio, 
even if they are not in the same group. However, for this action to take place both radios need to 
be on the same channel and time slot. This feature allows a radio user to carry a one-to-one 
conversation that is only heard by the two parties involved. For example, an employee may use a 
Private Call to privately alert a specific manager about a security incident, rather than placing a 
Group Call that would be heard by the whole group. Though Private Calls utilize the signaling 
capabilities in MOTOTRBO systems to govern which radios are allowed to participate, the use of a 
Private Call does not necessarily imply the use of encryption or scrambling. 

Private Calls can be configured as confirmed or unconfirmed on a per channel basis. For 
confirmed Private Calls, the calling radio transmits a short control signal message to the target 
radio. This signaling verifies the presence of the target radio before being allowed to start the call. 
The receiving user does not need to manually “answer” this signal, but rather the receiving radio 
automatically responds to the setup request. Once the receiving radio replies to the setup request, 
the initiating radio sounds a Talk Permit tone and starts the call. The receiving radio sounds a 
Private Call indication to the user, prior to relaying the received voice. Once a Private Call is set 
up, subsequent transmissions do not require the call setup messaging. For unconfirmed Private 
Calls, the calling radio does not transmit any control signaling before being allowed to start the 
call. Although there is no confirmation the radio is present on the system, an audible indication 
from the target user may act as confirmation. For example, “Joe are you there?”, “Yes, go ahead.”. 

It is important to understand the advantages and disadvantages of confirmed and unconfirmed 
operation as it relates to performance. In general, confirming radio presence increases the setup 
time (voice access time) of a Private Call since the user must wait for the control signaling to go 
through the radio network before acquiring a talk permit tone. Although this may take more time, it 
does guarantee that the target radio is present prior to providing the talk permit tone. When 
operating on an IP Site Connect system that is connected through the public internet, this time 
may be longer than when operating on a single site since the control messaging may be traversing 
through the internet. If the target radio is scanning or roaming, the setup time of a confirmed 
Private Call may increase due to the fact that the first control message may not successfully reach 
the scanning or roaming radio. The second attempt, which contains a preamble, has a higher 
likelihood of reaching the scanning or roaming radio. 

Since unconfirmed Private Calls do not transmit any control signaling, the additional setup time is 
not required and therefore the voice access time is shorter. Because setup messaging is not used 
prior to starting the call, it is possible that scanning or roaming radios may arrive late to a call. This 
could cause the user to miss the first few words of the transmission (no more than what is lost 
while scanning for a Group Call). In addition, the user must utilize an audible acknowledgement to 
validate presence when configured with unconfirmed Private Calls since no control messaging is 
used to confirm radio presence. 

In MOTOTRBO systems, capabilities for Private Calls are configured with the portable and mobile 
radio CPS. The repeater does not require any specific configurations for Private Calls. Radios can 
be configured to allow the user to select the recipient of a Private Call using the radio menu 
contacts list. Private Calls can also be mapped to a channel selection or a programmable button. 
Users can also manually dial the destination radio ID with the radio keypad. This means a radio 
can make a Private Call to any other radio that is on the channel, regardless of whether the radio 
has created a CPS Private Call entry for the target radio. A call receive tone, or call preceding 
tone, can be configured to alert the target user of the incoming Private Call. This can be enabled or 
disabled per individual radio. Greater detail on the fleetmapping process that governs who is 
allowed to make Private Calls and to whom, as well as an introduction to the CPS configuration 
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section for Private Calls, is provided in “System Design Considerations” on page 277 of this 
document. 

2.3.1.3 All Call 

All Call is a one way voice call between a privileged operator and all users on a logical channel. 
The transmitting radio utilizes a special All Call group that every radio on the same system and 
logical channel (regardless of group) will receive. 

In both Capacity Plus and Linked Capacity Plus systems, all the radios (including radios on busy 
channels, except the transmitting radio(s) and radios listening to Emergency Calls) listen to an All 
Call. The listening radios on a busy channel may take up to 350 ms to leave their channels and 
enter the All Call late. The transmitting radio on a busy channel only enters the All Call late, after 
finishing the ongoing transmission. If a radio initiates emergency while participating in an All Call, 
then the emergency transmissions are made on the Rest Channel and the radios interested to 
participate in the Emergency Call, leave the All Call to join the Emergency Call. 

Example: An All Call is occurring on Channel 1, and Channel 2 is the Rest Channel. The radio 
initiating an Emergency Call leaves Channel 1, moves to Channel 2, and starts the 
Emergency Call. The start of the Emergency Call is announced on Channel 1. This 
triggers the radios that want to participate in the Emergency Call to leave Channel 1 and 
move to Channel 2. 

As an All Call is considered a one-way transmission, users cannot talk back to an All Call. If the 
user transmits after receiving an All Call, he transmits using his currently selected group. An All 
Call follows the Admit Criteria of the selected channel. More information on the Admit Criteria is 
provided in “Channel Access Configuration” on page 417. 

All Calls do not communicate across different time slots or channels within the system. The ability 
to initiate an All Call is only programmed into radios that are used in supervisory roles. All other 
radios monitor All Call transmissions by default. This feature is very useful when a supervisor 
needs to communicate with all the users on a logical channel, rather than just a particular group or 
individual. 

In MOTOTRBO systems, capabilities for All Calls are configured with the portable and mobile 
CPS. The repeater does not require any specific configurations for All Calls. Radios can be 
configured to enable the user to select an All Call via the radio menu contacts list. All Calls can 
also be mapped to a channel selection or a programmable button. A call receive tone, or call 
preceding tone, can be configured to alert the target user of the incoming All Call. Greater detail on 
the fleetmapping process governs who is allowed to make All Calls, as well as an introduction to 
CPS configuration section for All Calls, is provided in “System Design Considerations” on 
page 277 of this document. 

2.3.1. 4 DTMF Hot Keypad 

When this feature is enabled, the numeric keypad allows live dialing during dispatch operation. 
During a voice call, the user can transmit the following characters using a MOTOTRBO radio with 
keypad: 0123456789*#. These characters are encoded as dual tone multi frequency 
(DTMF). These DTMF tones enable the user to communicate with a device connected to a control 
station using the numeric keypad. 
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This feature is supported in single site conventional, IP Site Connect, Capacity Plus and Linked 
Capacity Plus system configurations. This feature is also supported by radios in analog mode. 

WARNING: Because a phone patch call needs other call processing requirements in addition to 
DTMF tones, simply connecting an APP box to the control station does not enable the 
phone patch call capability. If phone patch calls need to be supported, please use the 
configurations defined in the DTP feature. See “Digital Telephone Patch (DTP)” on 
page 342. 

2.3.2 Transmit Interrupt 

The Transmit Interrupt feature is a suite of features proprietary to Motorola. This feature generally 
allows a radio to shut down an ongoing clear, Basic Privacy, or Enhanced Privacy interruptible 
voice transmission, and potentially initiate a new transmission. Transmit Interrupt is independent of 
call type, therefore it applies to Group Calls, Private Calls, Emergency Calls and All Calls. This 
feature also applies to Private Calls that are initiated via remote monitor command, and Group 
Calls that are initiated via emergency remote monitor. 

For software version R01 .06.00, this feature is supported on digital direct channels, digital 
repeater channels and IP Site Connect local channels. For software version R01 .07.00 or later, 
this feature is also supported on Capacity Plus system configurations and IP Site Connect wide 
area channels. For IP Site Connect wide area channels, a repeater can use this feature to stop a 
voice transmission where a radio continues to transmit even after failure of arbitration. This also 
provides feedback to the transmitting radio that the transmission is not repeated over-the-air and 
allows the radio to participate in a call started by another radio. 

Transmit Interrupt is also supported on Linked Capacity Plus system configurations. 

To support different use cases, Transmit Interrupt has four unique variations: 

• Voice Interrupt: This feature allows a radio that is unmuted to an interruptible voice call, 
to stop the ongoing voice transmission and initiate its own voice transmission to the 
same call membership. Voice Interrupt is typically used during a prolonged voice 
transmission when “late-breaking” or urgent information becomes available, and it is 
necessary to disseminate the information to the group as quickly as possible. 

• Emergency Voice Interrupt: This feature allows a radio to stop any ongoing 
interruptible voice transmission, and initiate its own emergency transmission. 
Emergency Voice Interrupt gives a radio an improved access to the radio channel, in an 
emergency condition. 

• Remote Voice Dekey: This feature allows a radio to stop an ongoing interruptible voice 
transmission. It is typically used by a supervisor to remotely dekey a radio that is 
inadvertently transmitting (e.g., the PTT is inadvertently pressed for an extended period 
of time) and occupying the radio channel. 

• Data Over Voice Interrupt: This feature allows a third-party data application on an 
option board or attached PC to control the radio in order to stop any ongoing 
interruptible voice transmission and initiate its own data message transmission. The 
application can also specify in the data message, an option to discard itself, if an 
ongoing voice transmission is not interruptible. This feature is useful in situations where 
data traffic is more important than voice traffic. Data Over Voice Interrupt is not used by 
any data applications native to the radio (e.g., Text Message, Location, and Telemetry 
do not use Data Over Voice Interrupt). 
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While receiving a Direct Mode/Dual Capacity Direct Mode (DCDM) transmission, a radio may use 
the Transmit Interrupt feature to remotely dekey the transmitting radio and begin its own Direct 
Mode or Repeater Mode transmission. Similarly, while receiving a Repeater Mode transmission, a 
radio may use the Transmit Interrupt feature to remotely dekey the transmitting radio, and begin its 
own Repeater Mode transmission. However, the radio may not use the Transmit Interrupt feature 
to remotely dekey the transmitting radio’s Repeater Mode transmission and begin its own Direct 
Mode transmission. This scenario is not supported because Transmit Interrupt dekeys only the 
radio’s transmission within a channel (timeslot), but does not dekey the repeater which remains 
keyed on the Direct Mode carrier frequency, and supports two channels (timeslots). The repeater 
is not dekeyed because this may interfere undesirably with a call in the other channel (timeslot) 
supported by that repeater. 

Provisioning of the Transmit Interrupt feature in general, is separated into two basic categories: 

1. Radios that have the ability for voice transmissions to be interrupted. 

2. Radios that have the ability to initiate transmit interrupt commands. 

NOTE: The radios may be provisioned with none, one, or both of these capabilities. 

There are a few important items to consider before provisioning of the Transmit Interrupt feature: 

• The Transmit Interrupt feature is supported in digital direct mode, single site repeater 
mode, on both local and wide area slots of the IP Site Connect mode, Capacity Plus, 
and on Linked Capacity Plus system configurations. 

• In Capacity Plus and Linked Capacity Plus configurations, an All Call can only be 
stopped by Emergency Voice Interrupt. Voice Interrupt, Remote Voice Dekey, or Data 
Over Voice Interrupt features are not supported. 

• Because the Transmit Interrupt features are proprietary to Motorola and use some 
proprietary signaling (i.e., manufacturer-specific extensions that comply to the ETSI 
DMR Tier 2 standards), non-Motorola radios may not be able to unmute to an 
interruptible voice transmission and Motorola radios may not be able to interrupt a non- 
Motorola radio’s voice transmission. Hence, it is highly recommended to assign radios to 
separate groups and/or channels. This classifies radios provisioned with Transmit 
Interrupt capability from the radios that are not provisioned with the capability. 

• In Direct Mode, Transmit Interrupt can typically clear an interruptible voice transmission 
from the channel in less than two seconds. In Single Site Repeater Mode, Transmit 
Interrupt can typically clear an interruptible voice transmission from the channel in less 
than three seconds. The Transmit Interrupt feature provides one automatic retry in the 
event that the first interrupt attempt fails due to corrupt signaling (e.g., RF coverage 
degradation, signaling collisions with other radios, etc.). The retry essentially doubles 
the times shown above. If the radio user still needs to interrupt after the failed retry, the 
user needs to initiate another service request. 

• VOX is not compatible with the Transmit Interrupt feature. Therefore, VOX is prevented 
from operating when any of the Transmit Interrupt features are enabled. 

NOTE: For the Transmit Interrupt feature to operate consistently, all radios using the channel 
should be provisioned with the ability to be interrupted. If some radios are provisioned 
without the ability to be interrupted (e.g. normally desirable for a supervisor’s radio), then 
those radios’ transmissions cannot be interrupted. 
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2.3.2. 1 Upgrading a System to be Transmit Interrupt Capable 

There are several considerations when upgrading a deployed system that presently do not support 
the Transmit Interrupt feature, 1 to become Transmit Interrupt capable. 

For systems that use a XPR 8300/XPR 8380/XPR 8400 repeater, the repeater software version 
must be upgraded to R01 .06.00, or later. 

For systems that do not use privacy exclusively (See “Voice and Data Privacy” on page 99), radio 
transmissions with privacy disabled and interruptible voice enabled cannot be received by radios 
using software versions prior to R01.06.00. 

For systems that use privacy exclusively, there are no major concerns receiving radio 
transmissions with both privacy and interruptible voice enabled; provided the older release 
supports the type of privacy being used by the radio provisioned with software version R01.06.00 
or later. 

To minimize service disruption during the upgrade period, systems that do not use privacy 
exclusively may be upgraded using the following approach: 

• Provision new radios with software version R01 .06.00 or later. Configure two channels; 
one channel with Transmit Interrupt features enabled, and the other channel with all 
Transmit Interrupt features disabled. During the upgrade, the channel with all Transmit 
Interrupt features disabled is used. 

• Individually upgrade previously deployed radios to software version R01.06.00 or 
later, and provision with the two channels described above. The channel with all 
Transmit Interrupt features disabled is then used during the upgrade. 

• For systems that use a repeater, the repeater may be upgraded to be Transmit Interrupt 
capable at any time. Finally, once all radios have been upgraded to the compatible 
software version, the channel with the Transmit Interrupt features enabled is used by all 
radios on the system. 

2.3.3 Digital Signaling Features 

We have already described how digital calls utilize digital vocoding and error correction coding 
processes, and that a given digital call occupies a single logical channel (frequency and TDMA 
time slot). Within a given time slot, the digital call is organized into voice information and signaling 
information. Included in the signaling information is an identifier used to describe the type of call 
that is transmitted within the time slot (e.g. Group Call, All Call, or Private Call). Signaling 
information also includes identification information and/or control information, which is used to 
notify listeners on a voice call of system events and status (e.g. the ID of the transmitting radio and 
the group ID). Because this information is repeated periodically during the course of the call, this 
embedded signaling allows users to join a voice transmission that is already in progress and still 
participate in the call. This is referred to as Late Entry, and is an advantage over analog signaling 
schemes. 



1. Systems that are running on software versions R01.01.00 - R01.06.00, or later which has the Transmit 
Interrupt feature disabled in the CPS configuration, or non-Motorola equipment, etc. 
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2.3.3. 1 PTT ID and Aliasing 

This feature allows the target radio to identify the originator of a call. If programmed with the radio 
CPS (Customer Programming Software), a user friendly alphanumeric name or “alias” can also be 
displayed. These user friendly aliases are also used when initiating voice calls and digital signaling 
features. The alias information in the transmitting radio should correspond with the alias 
information in the receiving radio. The transmitting radio ID is sent over-the-air and, if there is an 
alias for that ID in the receiving radio, the receiving radio displays the alias. If no alias is configured 
at the receiving radio for that ID, then only the transmitting radio's ID is shown. 

2. 3. 3. 2 Radio Enable/Disable 

There are two ways to enable/disable a radio: 

• by another radio, typically in a supervisory role, that sends Inhibit/Uninhibit command 

using over-the-air signaling, or 

• by a third-party application connected to the repeater, that sends Inhibit/Uninhibit 
command using the ADP application. 

2. 3. 3. 2.1 Using Over-the-Air Signaling 

The Radio Disable feature can be used to stop any inappropriate use of a radio, or to prevent a 
stolen radio from functioning. In MOTOTRBO systems, Radio Disable is configured in the portable 
and mobile radios with the CPS. To allow a radio to use this function, it must be enabled in the 
CPS “Menu” settings. To permit (or prevent) a radio from receiving and responding to this 
command, go to the “Signaling Systems” settings in the CPS. 

When disabled, the radio's display blanks and the radio is no longer able to make or receive calls. 
The radio can still be turned on and off; this indicates that the radio has not failed, but is disabled. 
Once disabled, a radio can also be enabled via the CPS. All radios are configured to accept Inhibit 
commands by default, but this can be disabled via the CPS. 

For over-the-air radio enable signaling to be successful, the target radio must be turned on and be 
within coverage of the site it was disabled at. This is important since a disabled radio locks onto 
the site or channel on which it was disabled, even after a power cycle. To receive an enable 
command over-the-air, the radio also has to be within coverage of the site where the disabling 
occurred. This may also be accomplished by communicating with the radio on the talkaround 
frequency of the site in which it was disabled. 

2. 3. 3. 3 Remote Monitor 

The Remote Monitor feature allows a remote user to activate a target radio’s microphone and 
transmitter for a period of time. A call is silently set up on the target radio, and its PTT is controlled 
remotely without any indications given to the end user. The duration that the target radio transmits 
after receiving a Remote Monitor command is set in the target radio through the CPS. When 
receiving the Remote Monitor command, the target radio initiates a Private Call back to the 
originator of the Remote Monitor command. 

This feature is used to ascertain the situation of a target radio which is powered-on, but is 
unresponsive. This is beneficial in a number of situations including: 
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• theft, 

• incapacity of the radio user, or 

• allowing the initiator of an Emergency Call to communicate hands-free in an emergency 
situation. 

In MOTOTRBO systems, Remote Monitor is configured in portable and mobile radio CPS. To allow 
a radio to use this function, it must be enabled in the CPS “Menu” settings. To permit (or prevent) a 
radio from receiving and responding to this command, go to the “Signaling Systems” settings in the 
CPS. When a radio is configured to decode the remote monitor command, the duration that the 
target radio transmits after receiving a Remote Monitor command is also set in the CPS “Signaling 
Systems” settings of the target radio. 

The Remote Monitor feature may be activated on a disabled radio. Remote Monitor could also be 
programmed to be activated on radios that are in emergency mode only. 

2. 3. 3.4 Radio Check 

The Radio Check feature checks if a radio is active in a system without notifying the user of the 
target radio. Besides the Busy LED, there is no other audible or visual indication on the checked 
radio. The receiving radio automatically and silently responds with an acknowledgement to the 
initiating radio. 

This feature is used to discreetly determine if a target radio is available. For example, if a radio 
user is non-responsive, Radio Check could be used to determine if the target radio is switched on 
and monitoring the channel. If the target radio responds with an acknowledgement, the initiator 
could then take additional action such as using the Remote Monitor command to activate the 
target radio’s PTT. 

In MOTOTRBO systems, Radio Check is configured in portable and mobile radio CPS. To allow a 
radio to use this function, it must be enabled in the CPS “Menu” settings. All MOTOTRBO radios 
will receive and respond to a Radio Check, i.e. this feature cannot be turned off in the CPS. 

2. 3. 3. 5 Call Alert 

The Call Alert feature allows a radio user to essentially page another user. When a radio receives 
a Call Alert, a persistent audible and visual alert is presented to the user. The initiator of the Call 
Alert is also displayed. If a user is away from his radio at the time of the reception, the alert 
remains until the user clears the Call Alert screen. If the user presses the PTT while the Call Alert 
screen is active, he starts a Private Call to the originator of the Call Alert. For in-vehicle 
applications, this is often used in conjunction with the Horn and Lights option. When a user is away 
from his vehicle, a Call Alert can initiate the vehicle’s horn and lights to sound and flash, which 
notifies the user to return to the vehicle and call the originator. 

In MOTOTRBO systems, Call Alert is configured in portable and mobile radio CPS. To allow a 
radio to use this function, it must be enabled in the CPS “Menu” settings. All MOTOTRBO radios 
will receive and respond to a Call Alert (i.e. you cannot disable this feature by using the CPS). 
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2. 3. 3. 6 Remote Voice Dekey 

The Remote Voice Dekey feature allows a radio user to stop any interruptible voice transmission, 
except for All Calls. This ability to remotely stop an interruptible voice transmission is provisioned 
into the radio via the CPS and accessed via a programmable button. 

NOTE: For the Remote Voice Dekey feature to operate consistently, all radios using the channel 
should be provisioned with the ability to be interrupted. However, not all need to be 
provisioned with the Remote Voice Dekey capability. 

If some radios are provisioned without the ability to be interrupted (e.g., normally desirable for a 
supervisor’s radio), then those radios’ transmissions cannot be interrupted and the radio user 
receives a Remote Voice Dekey Failure Tone if Remote Voice Dekey is attempted while receiving 
an uninterruptible transmission. The radios that are provisioned without the ability to be interrupted 
(e.g., a supervisor’s radio) may still be provisioned with the Remote Voice Dekey feature, which 
gives those radios the ability to interrupt another radio’s interruptible voice transmission. 

For this feature, the initiating radio is not required to be a member of the voice call that is being 
interrupted. Therefore, it is possible to interrupt a voice call, and then initiate a new call to a 
different group or individual. Once the original voice transmission is terminated via the Remote 
Voice Dekey feature, the interrupting radio user can initiate a new call via any of the available call 
initiation methods. 

When the programmable button is pressed and an interruptible voice transmission is on the 
channel, the radio attempts to stop the interruptible voice transmission. If the radio succeeds at 
interrupting the voice transmission, the radio user receives a Remote Voice Dekey Success Tone 
when the channel is successfully cleared down. If the radio fails to interrupt the voice transmission, 
then the radio user typically receives a Remote Voice Dekey Failure Tone. Depending on the 
radio’s CPS configuration, the radio user whose transmission was interrupted may or may not 
receive a Talk Prohibit Tone until the PTT is released. 

2.3.4 Digital Emergency 

MOTOTRBO offers a variety of emergency handling strategies that will fit the customer’s 
organizational needs. In its basic form, MOTOTRBO provides the ability for a radio user in distress 
to send a confirmed emergency alarm message, and emergency voice to a user on a supervisory 
radio. The emergency alarm message contains the individual radio ID of the initiator. Upon 
reception of an emergency alarm, the supervisor receives audible and visual indications of the 
emergency and the initiating radio ID is displayed. Depending on configuration, emergency voice 
may follow between the initiator and the supervisor. Once the supervisor handles the emergency 
situation (i.e. solves the problem), he clears the emergency on the supervisor radio. Once the 
initiator clears his emergency on the initiator radio, the emergency is considered over. 

NOTE: A radio will not roam while reverted to a channel due to an emergency or when Active Site 
Search is disabled. Reference the site roaming section for details on the interactions 
between emergency and roaming. 

Each mobile radio can program the Emergency Alarm to any of the programmable buttons, 
whereas for the portable radio the Emergency Alarm can only be programmed to the orange 
button. The Emergency Alarm can also be triggered externally through a footswitch for a mobile 
application or any other applicable accessory. Pressing the emergency button causes the radio to 
enter emergency mode, and begin its emergency process. 
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When a user presses the Emergency button, the radio gives audible and visual indications to show 
that it has entered emergency mode. There is a CPS configurable option available, referred to as 
Silent Emergency, which suppresses all indications of the emergency status on the user’s radio. 
This feature is valuable in situations where an indication of an emergency state is not desirable. 
Once the user breaks radio silence by pressing the PTT and speaking, the Silent Emergency 
ends, and audible and visual indications return. 

When the user’s radio is in the emergency mode, various other features are blocked that may 
distract him from his communication with the supervisor. For example, the user will not be able to 
initiate other features such as Scan, Private Call, or other command and control functions. 

Once the emergency is complete (e.g. turn off and turn on the radio, or long/short press of the 
emergency button depending on the radio configuration) these abilities will return. 

The emergency sequence is generally made up of two major parts: 

• the signaling and 

• the following voice call. 

The emergency alarm is sent first, and depending on configuration is commonly followed up by an 
Emergency Call. 

An emergency alarm is not a data service, but rather a confirmed command and control signaling 
that is sent to a group. More than one radio can be configured on the system to monitor that group, 
and be designated to acknowledge emergency alarms for that group. These radios are considered 
acknowledging supervisors. There is no user level acknowledgement. The supervisor radio 
automatically acknowledges the emergency, and provides an alert to the supervisor radio user. 
There are other radios that are designated to only monitor emergency alarms, but are not 
permitted to acknowledge them; these users are commonly referred to as non-acknowledging 
supervisors. Thus, sending the emergency alarm to a group allows for multiple supervisors to 
receive the emergency alarm indication. It is important that only one acknowledging supervisor 
should be configured per group and slot; otherwise there may be contention between the 
acknowledgements. 

The supervisors retain a list of received emergency alarms so that they can keep track of multiple 
emergencies. Once cleared, the emergency alarm is removed from the list, and the next one is 
displayed. These emergencies are displayed in a last-in-first-out sequence. The supervisor has 
the ability to hide the emergency alarm list, so he can contact service personnel to attend to the 
received emergency situation. The channel where the emergency alarm was received is displayed 
to aid the supervisor when changing channels. 

If the user follows up the Emergency Alarm with a voice call while in the emergency mode, his 
transmission contains an embedded emergency indication. Any radio user can be configured to 
display this embedded emergency indication. Emergency Calls are always processed with an 
admit criteria of Always. This allows the Emergency Call to transmit regardless of the current 
channel activity. If there is another radio currently transmitting, contention may occur. 

The initiating radio supports a feature that is tied to silent emergency and the Emergency Call. The 
“Unmute Option” prevents the radio from receiving voice traffic after initiation of a Silent 
Emergency. In situations where an indication of an emergency state is not desirable, it is important 
to be able to mute incoming voice, that may give away the initiators emergency state. Once the 
user breaks radio silence by pressing the PTT and speaking, the radio returns to its normal 
unmute rules. 
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Silent emergency and the unmute options have no effect on data. It is the responsibility of the end 
user to make sure data is not sent to a terminal that would divulge any emergency state. 
Transmission of data does not clear Silent Emergency. 

The channel and group on which a user transmits his emergency is crucial to properly contacting a 
supervisor. MOTOTRBO offers the ability for a user to transmit the emergency on a selected 
channel or to automatically change to a predetermined channel to transmit his emergency. 

Transmitting an emergency on a selected channel (referred to as a “tactical” emergency) is often 
useful on small systems where there are only a few groups of users. Each group has its own 
specified user that handles emergencies. 

Automatically changing to a predetermined channel, referred to as “reverting”, is often useful in 
systems that have a dispatch style emergency strategy. Users in various groups and channels are 
configured to revert to a specific channel and group to process an emergency. This allows one 
user to monitor an “Emergency” group, and all other users revert to him in case of an emergency. 
This minimizes the possibility of supervisors missing emergencies on one channel, while 
monitoring other channels. After the emergency is cleared, all users revert back to the selected 
channel they were on before the emergency. In MOTOTRBO systems, the Emergency Revert 
Channel is configured in portable and mobile radio CPS at the Digital Emergency Systems 
settings. 

The Capacity Plus and Linked Capacity Plus systems do not support a revert channel for 
emergency. The start of an Emergency Call is announced over all busy channels. This allows a 
listening radio that is interested in joining the Emergency Call, to leave its channel and join the 
Emergency Call. A radio is interested in an Emergency Call if the emergency group is either the 
Tx-Group, or is in the Rx-Group list of the radio. A radio listening to an Emergency Call (e.g., el) 
joins another Emergency Call (e.g., e2), only if the e2’s group has a higher priority than the el’s 
group. The first priority is the Tx-Group, followed by any Rx-Group in the Rx-Group list of the radio. 

The Capacity Plus and Linked Capacity Plus systems ensure that an Emergency Call should start 
on a channel where the users monitoring the “Emergency” group are present. There are some 
behavior differences in software versions R01.05.00 - R01.07.00. This is shown in the following 
flowchart: 
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Emergency Call is 
transmitted impolitely over 
the ongoing All Call because 
all radios are on the channel 
where All Call is active. 



R01. 05.00 



Is All Call active? 



Emergency Call is transmitted 
over the ongoing Emergency Call 
because the receiving radios are 
on this channel. In R01.05.00 and 
R01 .06.00, it is transmitted 
‘impolitely’. In R01 .07.00 or later, 
Transmit Interrupt is used to stop 
the ongoing call. 



Is an Emergency Call for the' 
same Talkgroup active? 



Emergency Call is transmitted 
over the idle Rest Channel. 



Is Rest Channel idleT 



In R01. 05.00, 
R01.06.00 



R01. 07.00 



Emergency Call is 
transmitted impolitely over 
the busy Rest Channel. 



Is call on busy Rest Channel 
interruptible? 



Transmit Interrupt is used to stop the 
ongoing call. Emergency Call is then 
transmitted on the idle Rest Channel. 



NOTE: A radio does not provide any audible indication to the user when the radio switches 
channels. However, the group display on the radio changes. 

NOTE: In software version R01.05.00, an Emergency Call may not be serviced if ALL of the 
following scenarios occur: 

• All Trunked Channels are busy. 

• A call for the emergency talkgroup is active on a channel. 
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• A radio powers on or joins the system after a long fade and the radio initiates an 
Emergency Call. In this instance, there is no radio to service the Emergency Call on the 
busy Rest Channel. 

There are three major methods to process the emergency alarm and the Emergency Call; all are 
configurable through the CPS. They are Emergency Alarm Only, Emergency Alarm and Call, and 
Emergency Alarm with Voice to Follow. 

The Linked Capacity Plus system handles an Emergency Call at the source site in the same way 
as in a R01.07.00 Capacity Plus system. If a Rest Channel is busy at a destination site, and the 
call is interruptible, then the ongoing call is interrupted for the Emergency Call to proceed. 
However, if the ongoing call is not interruptible, the Emergency Call starts impolitely. 

NOTE: The impolite Emergency Call is sent to the sites associated with the emergency talkgroup. 

2.3.4. 1 Emergency Alarm Only 

When configured for Emergency Alarm Only, the emergency process only consists of the 
emergency alarm part. The number of emergency alarm attempts and their admit criteria are 
configurable, and can even be set to retry indefinitely. The number of alarm attempts are controlled 
by CPS parameters in the Digital Emergency System settings; these parameters include the 
number of polite and impolite retries. The alarm is initially sent regardless of channel activity, and 
once the configured impolite attempts are exhausted, the polite retries are executed when the 
channel is idle. Emergency ends when: 

• an acknowledgement is received, 

• all retries are exhausted, 

• the user manually clears the emergency, or 

• the user pushes the PTT. 

No voice call is associated with the emergency when operating as Emergency Alarm Only. 
Pressing the PTT clears the emergency, and a standard voice call is processed. 
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2. 3.4. 2 Emergency Alarm and Call 

When configured for Emergency Alarm and Call, the emergency consists of the emergency alarm 
process followed by the ability to perform an Emergency Call. The number of emergency alarm 
attempts and their admit criteria are configurable, and can even be set to retry indefinitely. The 
alarm is initially sent regardless of channel activity, and once the configured impolite retries are 
exhausted, the polite retries are executed when the channel is idle. 

Emergency alarm stops when: 

• an acknowledgement is received, or 

• all retries are exhausted. 

The radio still remains in an emergency state. Any follow up PTT initiates an Emergency Call, and 
the call includes an embedded emergency indication. If the user presses the PTT before the radio 
sends an emergency alarm, the radio stops sending the alarm, and starts the Emergency Call. 
While in the emergency mode, all subsequent voice transmissions are Emergency Calls. The user 
remains in emergency mode until he manually clears emergency. The only way to reinitiate the 
emergency alarm process is to reinitiate the emergency. 
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2. 3.4. 3 Emergency Alarm with Voice to Follow 

When configured for Emergency Alarm and with Voice to Follow, the emergency consists of 
sending a single emergency alarm, and followed by an automatic transmission of an Emergency 
Call. This is referred to as hot microphone. The radio only sends one emergency alarm regardless 
if there is channel activity, and then without waiting for an acknowledgement the radio immediately 
activates the microphone and initiates an Emergency Call without the need of the user pressing 
the PTT. The duration of the hot microphone state is configurable through the CPS in the Digital 
Emergency Systems settings. This transmission is considered an Emergency Call, and therefore 
includes the embedded emergency indication. Once this hot microphone duration expires, the 
radio stops transmitting, but remains in the emergency mode. Any follow up PTT initiates an 
Emergency Call, and includes the embedded emergency indication. The user remains in the 
emergency mode until he manually clears his emergency. The only way to reinitiate the 
emergency alarm and the hot microphone is to re-initiate the emergency. 

It is important to note that when configured for Emergency Alarm with Voice to Follow, the radio will 
continue to transmit voice for the duration of the provisioned hot microphone timer. Since voice 
has priority over data, any data is queued while voice is transmitting, including the GPS update 
that was triggered by the emergency. The GPS data cannot be delivered until after the radio stops 
transmitting voice, and after the repeater hangtime has expired. The GPS data has no additional 
priority over other data queued in the radios, or over any traffic on the channel. Therefore, its 
delivery may be delayed if the radio in emergency has pending data queued or if the channel is 
busy processing other traffic. 

It is recommended when utilizing Emergency Alarm with Voice to Follow and GPS, that the hot 
microphone timer be at maximum 30 seconds. There are a few reasons for this. First of all, data 
messages will not stay in the queue for ever, 30 seconds is short enough so to give the GPS data 
a chance to be transmitted without timing out. Second, if the hot microphone timer is longer than 
30 seconds, and the GPS update rate is around the same value, then other GPS messages may 
start to fill up in the queue while the voice transmission is processing. This not only occurs with the 
radio in emergency, but with all other radios since the channel is busy. Therefore when the voice 
call ends, all radios will be attempting to access the channel with their GPS data which increases 
the likelihood of collisions and lost messages. Finally, it is important to understand that while the 
user is transmitting due to its hot microphone timer, there is no way to communicate back to him. 
Most users can explain their situation in less than 30 seconds and require some feedback from the 
emergency dispatcher much sooner. That is why it is recommended to keep this value low and if 
additional monitoring is required, the remote monitor feature can be utilized. Only use a long hot 
microphone timer in specialized applications. 

Also, since the emergency alarm itself is not acknowledged nor retried, its reliability is less than 
that of the standard Emergency Alarm and Emergency Alarm Only and Call. These considerations 
should be taken into account when choosing to operate with Emergency Alarm with Voice to 
Follow. 
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2. 3.4.4 Emergency Voice Interrupt for Emergency Alarm 

The Emergency Voice Interrupt feature, when enabled in a radio, is used during the initiation of an 
emergency condition when an interruptible voice transmission is already taking place on the 
channel. 

When an emergency is initiated with Emergency Voice Interrupt enabled, the radio attempts to 
interrupt an ongoing, interruptible voice transmission on the channel. The radio then uses the 
established procedures for either Emergency Alarm or Emergency Alarm with Call, depending 
upon the CPS configuration. For the Emergency Voice Interrupt for Emergency Alarm feature, the 
radio is not required to be a member of the voice call being interrupted. 

NOTE: For the Emergency Voice Interrupt for Emergency Alarm feature to operate consistently, 
all radios using the channel should be provisioned with the ability to be interrupted. 
However, not all need to be provisioned with the Emergency Voice Interrupt for Emergency 
Alarm capability. 

If some radios are provisioned without the ability to be interrupted (e.g., normally desirable for a 
supervisor’s radio), then those radios’ transmissions cannot be interrupted and the radio user 
instead transmits the Emergency Alarm in accordance with the configuration of the polite and 
impolite Emergency Alarm fields in the CPS, if Emergency Alarm is attempted while receiving 
another radio’s uninterruptible transmission. 

If the interruption of the voice transmission is successful, the radio uses the established 
procedures for either Emergency Alarm or Emergency Alarm with Call, depending upon the CPS 
configuration, once the channel has been cleared. Depending on the radio’s CPS configuration, 
the radio user whose transmission was interrupted may or may not receive a Talk Prohibit Tone 
until the PTT is released. 

If the interruption of the voice transmission fails, the radio then uses the established procedures for 
either Emergency Alarm or Emergency Alarm with Call, depending upon the CPS configuration. 
However, the probability of success diminishes because the original voice transmission had not 
been successfully cleared from the channel. 

If the voice call on the channel is not transmitting an interruptible voice signal, the radio uses the 
established procedures for either Emergency Alarm or Emergency Alarm with Call, depending 
upon the CPS configuration, again with a lower probability of success. 
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2. 3.4. 5 Emergency Voice Interrupt for Emergency Voice 

The Emergency Voice Interrupt feature, when enabled in a radio, is used during the initiation of an 
emergency voice transmission, primarily when an interruptible voice transmission takes place on 
the channel and the radio does not belong to that voice transmission. 

The radio attempts to interrupt the voice transmission, and then uses the established procedures 
for Emergency Voice Transmissions, when all of the following conditions are met: 

• Emergency Voice Interrupt is enabled. 

• The radio is in an emergency condition (e.g., the designated Emergency button was 
pressed previously). 

• Another radio’s interruptible voice transmission is taking place on the channel. 

• The radio in the emergency condition does not belong to the other radio’s voice 
transmission (i.e., the radio in the emergency condition is not receiving the other radio’s 
voice transmission). 

• The radio user in the emergency condition requests an Emergency Voice Transmission. 

The Emergency Voice Interrupt for Emergency Voice feature is not used when the radio belongs to 
the voice call is being interrupted. Instead, when the radio belongs to the call on the channel (i.e., 
the radio that is receiving the voice transmission), the “In Call Criteria” is used rather than the 
Emergency Voice Interrupt feature. This is because some systems may disallow radios to interrupt 
any call to which they belong. In this case, the user must wait until the receiving transmission has 
finished, before beginning their Emergency Voice transmission. 

The Emergency Voice Interrupt for Emergency Voice feature is also capable of interrupting an All 
Call provided the All Call is transmitting interruptible voice. 

NOTE: For this feature to operate consistently, all radios using the channel should be provisioned 
with the ability to be interrupted. However, not all need to be provisioned with the 
Emergency Voice Interrupt for Emergency Voice capability. 

If the radio succeeds at interrupting the voice transmission, the radio uses the established 
procedures for Emergency Voice Transmissions, once the channel has been cleared. Depending 
on the radio’s CPS configuration, the radio user whose transmission was interrupted may or may 
not receive a Talk Prohibit Tone until the PTT is released. If the radio fails to interrupt the voice 
transmission or the voice transmission is not interruptible, the radio also uses the established 
procedures for Emergency Voice Transmissions. However, the probability of success diminishes 
because the original voice transmission had not been successfully cleared from the channel. 
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2.3.5 Restricted Access to System (RAS) 

The Restricted Access to System (RAS) feature prevents unauthorized subscriber users from 
using the repeaters in the system to transmit to their targeted user or user groups. Additionally, 
RAS provides limited protection to prevent unauthorized subscribers from listening to any repeater 
outbound voice/data/CSBK transmission. The unauthorized subscriber device could be a Motorola 
subscriber, or a DMR-compatible subscriber from other vendors. However, RAS is not a privacy 
feature and if voice privacy is a concern, Basic Privacy, or Enhanced Privacy should be used. See 
“Types of Privacy” on page 99 for details. 

This feature supports all existing ADP interfaces and is supported in all MOTOTRBO system 
configurations - Conventional Single Site, IP Site Connect, Capacity Plus, and Linked Capacity 
Plus. 

This feature provides two methods to prevent a subscriber from accessing the system: RAS Key 
Authentication and Radio ID Range Check. These two methods are independent of each other 
and may be enabled/disabled separately or together. When used together, they provide a robust 
and flexible way to control the subscribers’ access to the system. 

2.3.5. 1 Restricted Access to System (RAS) Key Authentication 

In this method, both the repeater and subscriber are configured with a secret RAS key via CPS. 
When a subscriber transmits, the subscriber uses its configured RAS key to encode the bursts. 
When a repeater receives the bursts, the repeater also uses its configured RAS key to decode the 
bursts. If the RAS keys in the subscriber and repeater are the same, the repeater decodes and 
repeats the bursts successfully. However, if the subscriber does not have a RAS key or its RAS 
key does not match the one configured in the repeater, the decoding process in the repeater fails, 
and the transmission is blocked at the repeater. Therefore, the bursts from the unauthorized 
subscriber are not repeated and cannot reach the targeted user or user group. 

This method is secure and difficult to break or circumvent, because the RAS ID length ranges from 
6 to 24 characters. The algorithm is very robust. However, this method requires CPS 
configurations in the subscriber’s codeplug, resulting in more time and extra effort, when changes 
have to be made to a fleet of radios. 

2. 3. 5. 2 Radio ID Range Check 

In this method, up to 64 radio ID ranges can be provisioned in the repeaters. Each of these radio 
ID ranges may be configured as allowed or left as un-configured. If the radio ID is within any of 
the allowed radio ID ranges when the repeater receives a transmission from a subscriber, the 
repeater repeats it normally. However, if the subscriber’s radio ID is not within any of the allowed 
radio ID ranges, the repeater blocks the transmission. Hence, the transmission from unauthorized 
subscribers are not repeated and cannot reach the targeted user or user group. 

This method only requires configurations in the repeaters. Therefore, it is very easy to make 
changes quickly. However, an unauthorized user may analyze the radio transmission over-the-air, 
or use other means to guess some allowed radio IDs and create clones of authorized IDs, thus 
gaining access to use the repeater. 
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2.3.6 Digital Voting 

In a two-way radio system, a receive-and-transmit repeater is typically located at an elevated area 
such as the top of a hill or tall building, and has a high powered transmitter so that all the 
subscribers operating within the desired service area can receive signals at an acceptable 
strength. However, the mobile and portable subscribers typically have considerably smaller 
transmitted power because of size and cost considerations. The result is that while all the 
subscribers within the service area of the repeater can receive the transmissions, the repeater 
may not receive the transmissions from the subscribers, or may receive the transmissions at 
signal strengths that are too low to provide reliable communications. In other words, the talk-in 
range of the repeater is typically significantly less than its talk-out range. 

To resolve this imbalance, multiple receive-only repeaters (satellite receivers) can be installed at 
various locations throughout the service area to relay the radio’s transmission to the repeater. 
Once a satellite receiver receives an acceptable signal transmitted by the radio, the signal can be 
relayed back to the repeater over the IP network. Then the repeater repeats the relayed signal at a 
sufficiently high power level such that all radios in the service area are able to receive it. 

However, depending on where the transmitting radio is, the repeater itself (via its internal receiver) 
and other satellite receivers may also receive the radio’s transmission at an acceptable signal 
strength level. In this case, the repeater receives multiple copies of the same transmission from 
different receivers, selects one best copy of the received transmission, and ignores the rest. This 
selection is accomplished by a “voting” process. Typically, the voting process analyzes each 
received signal and determines which one is the best based on the signal-to-noise ratio of the 
signal or a bit error rate. 

By selecting the best signal copy among all the receivers, an additional benefit of voting is 
reducing the effects of local interference or fading, thus improving voice and data quality. 

The digital voting feature is the voting solution for MOTOTRBO digital radio systems. To achieve 
the best voting result, the voting selection is executed at the smallest possible level, known as the 
burst level, and is called continuous voting. MOTOTRBO digital voting is available in all system 
configurations - Digital Conventional Single Site, IPSO, Capacity Plus, and LCP. 

Digital voting is available starting from software version R02.30.02 onwards. Any repeaters prior to 
those versions will have to be upgraded in order to operate properly in a voting enabled system. 
Radios with firmware: R01.11.02 and above for MOTOTRBO, R02.06.04 and above for 
MOTOTRBO 2.0 are compatible with digital voting. 

2.3.7 CSBK Data 



This feature aims to improve the data communication performance and reliability, by using a data 
transmission method called “CSBK data”, whereby a single CSBK is used to transmit the ARS, 
GPS and XCMP device raw data. The OTA transmission time is reduced to one (1) burst. 
Therefore chances of channel collision are reduced, and the system capacity of enhanced GPS is 
enlarged greatly. An XCMP device can send multiple single CSBKs to other XCMP devices; the 
same CSBK can be transmitted repetitively to improve reliability. 

NOTE: The XCMP device here refers to an option board (OB) or a non-IP peripheral device. 
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2.3.7. 1 Supported Data Service 

• The ARS data that originates from the radio or the server. 

• The GPS data that originates from the radio or the XCMP device targeted to the server. 

• The raw data that originates from the XCMP device and targeted to the server. 

• Data from XCMP device to XCMP device can be sent as one CSBK or multiple single 
CSBKs. Multiple single CSBKs are only supported in direct mode. 

2. 3. 7. 2 Impacted Features 

• Enhanced GPS - Enhanced GPS with window sizes 5, 6, 7, 8, 9, 10 are compatible with 
CSBK data compression. Window sizes 1 and 2 are introduced to generate high data throughput. 

• Battery Save and Scan Preamble - CSBK data follows the unconfirmed data method for 
Battery Save and Scan Preamble CSBK. There is no preamble for the CSBK data targeted to the 
server. 

• Enhanced Channel Access - CSBK data follows the unconfirmed data method for ECA. 

• GPS Revert - Location CSBK data follows the unconfirmed GPS data method for GPS 
revert. 

2. 3. 7. 3 Improved Third-Party Interfaces 

The following is a list of improved third-party interfaces categorized by repeater and radio: 

1. Repeater 

• Repeater Call Monitor - monitors CSBK data 

• Wireline Protocol - routes CSBK data to the wireline gateway 

2. Radio 

• XCMP - transmits as CSBK data, and transmits at the Enhanced GPS channel 

• ARS - transmits as CSBK data 

• LRRP - transmits as CSBK data 

2. 3. 7.4 Affected System Components 

The following is a list of system components affected by the CSBK data feature: 

• Repeater - only supported by MTR3000 and 32 MB XPR Series 

• Radio - only supported by R02.08.00 and later 

• CPS 

• MNIS 

• ARS (DDMS), LRRP and Raw Data Applications 
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2.4 MOTOTRBO Integrated Data 

2.4.1 Overview 



When performing in digital mode, any MOTOTRBO radio can be used as an integrated voice and 
data radio, where the radio can send voice as well as data messages on a given logical channel. 
This does not refer to data services like enabling users to surf the web, send video images, or 
synchronize their office desktops. This is not the right technology for such bandwidth-hungry 
applications. However, it is a great technology for productivity-enhancing applications like 
messaging, location based services, simple database queries, bar code reading, and fill-in-the- 
form type of applications. Additionally, it is built into the MOTOTRBO system, so there are no 
monthly fees or dependencies on public carrier services, and customers control what applications 
their users can access. 

The MOTOTRBO system provides reliable data communications throughout the same areas 
where the system provides readily usable voice communications. However, there is a trade-off 
between the desired RF coverage area for data and the data throughput of the system. Extending 
the range of a system's operation requires more data message retries to successfully complete 
confirmed transactions, thus lowering throughput. 

Integrating voice and data on the same channel brings several benefits. These include: 

• Use of one RF channel for both voice and data. 

• Use of one system infrastructure for both voice and data. 

• Use of one subscriber to send and retrieve both voice and data messages over-the-air. 

Integrating voice and data on the same channel also brings several considerations. These include 
the following: 

• Traffic loading 

• Customer application requirements 

• Contention of voice and data. 

“System Design Considerations” on page 277 of this document provides practical guidance on the 
above considerations. 
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MOTOTRBO supports data services in a number of ways. 

• MOTOTRBO allows radios to send “unit-to-unit” and “unit-to-group” data packets. It 
supports confirmed and unconfirmed delivery of a data packet. The table below shows 
the confirmed and unconfirmed mode for all the software versions. 



Call Type/ 
Release 


R01.01.00 - R01.03.00 


R01. 04.00 


R01 .05.00 -R01. 06.00 


Unit-to-Unit 


Confirmed 


Confirmed 


CPS selectable for a 
personality. Confirmed (by 
default) 


Exception: In IP Site Connect, location data is 
always sent unconfirmed. 


Unit-to-Group 


Unconfirmed 



NOTE: If some of the radios are still running on older software versions like R01.00.00 or 
R01 .01 .00, then the radios must select the unit-to-unit data as confirmed mode. 

• MOTOTRBO also enables infrastructure and/or PC based applications by supporting 
Internet Protocol (IP) addressing and IP packet data services. Rather than relying upon 
external modems, MOTOTRBO radios can connect directly to computer equipment with 
standard USB interfaces. This simplifies and lowers the cost of integrating with 
applications, and at the same time expands the universe of potential applications that 
organizations can deploy. Depending upon availability in your region, Motorola offers 
two PC based MOTOTRBO applications: 

• MOTOTRBO Location Services and 

• MOTOTRBO Text Messaging. 

• MOTOTRBO supports an Application Developers Program. This program includes a 
complete application developer’s kit that fully describes interfaces for IP data services, 
command and control of the radio, and for option boards that can be installed in the 
radio. 

For some infrastructure based data applications, such as MOTOTRBO Location Services and 
MOTOTRBO Text Messaging, the radio must first complete a registration process before data 
messages can be exchanged between the radio and the infrastructure based application. 
Registration has no impact on voice operation, aside from utilizing the same channel. Polite voice 
calls will have to wait until an in-progress registration completes before it can use the channel, 
while impolite voice calls can transmit on top of a registration transmission. A radio does not have 
to register for voice services. A radio registers when the radio powers up in a data capable mode, 
or changes into a data capable mode. A radio registers with a Presence Notifier, which is 
incorporated within the MOTOTRBO Location Services and MOTOTRBO Text Messaging 
applications, but may also be utilized with third-party applications. The Presence Notifier informs 
the data application servers that the registered radio is “on the system” and available for services. 

In MOTOTRBO systems, the codeplug configuration determines whether or not a radio attempts to 
register on the selected channel. This is defined via the ARS parameter which is enabled or 
disabled through the settings within each channel. It must be set to enabled for those channels 
that are utilized for data communications with infrastructure based applications, such as 
MOTOTRBO Location Services and MOTOTRBO Text Messaging. Besides device registration, if 
enabled via CPS, the radio also allows the radio user to register using his/her user id with the 
support from additional 3rd party application. 
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2.4.2 Text Messaging Services 

Multiple MOTOTRBO system components interact together to deliver text messaging services. 
These include the built-in text messaging capabilities of MOTOTRBO subscriber radios and the 
MOTOTRBO Text Messaging Services application. The MOTOTRBO Text Messaging Services 
application in turn consists of several components, including the MOTOTRBO Mobile Text 
Messaging Client used with fielded radios, the MOTOTRBO Text Messaging Client used with 
dispatch-oriented positions, and the MOTOTRBO Text Messaging Server. The services provided 
by each of these components are described in the following subsections. 






Internet 



Cell phone or e-mail 
addressable device 



Application Server 
•Presence Notifier 
•Text Messaging Server 
•Text Messaging Dispatch 
•MCDD 




Fixed Clients (Dispatcher) 
MOTOTRBO Text Messaging Client 



Figure 2-8 Text Messaging Services 

Figure 2-8 shows a sample MOTOTRBO Text Messaging system configuration. See “System 
Components and Topologies” on page 185 for more details on setting up your MOTOTRBO 
system. 

Refer to the MOTOTRBO Network Interface Service (MNIS) and MOTOTRBO Device Discovery 
and Mobility Service (DDMS) sections for details on data communication with applications through 
a repeater network interface, instead of a control station. 

2.4.2. 1 Built-In Text Messaging Service 



The built-in text messaging feature allows MOTOTRBO portable and mobile radio users to send 
and receive information in a text format. This feature provides a useful alternative to voice on the 
MOTOTRBO system. The built-in text message service is fully accessed from the menu system on 
MOTOTRBO radio models with keypads and displays. Some aspects of this service are also 
available to non-display models. 
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2.4. 2. 1.1 Services Provided to a Radio User 

Using the built-in text messaging services, a radio user can create, send, receive, store and 
display a text message. The following capabilities are included: 

• A radio user can create a text message in one of two ways: Quick text or limited free- 
form text messages. Quick text messages are pre-defined using CPS. This allows a 
user to choose from commonly sent messages without having to retype the content. 
Once selected, the user is allowed to edit any part of the Quick text message prior to 
sending. The CPS allows you to define 10 Quick Text messages. 

• A radio user can select to send a text message to other radios. Messages can be sent to 
an individual or to a group. When a message is sent to an individual, the sender 
receives an acknowledgement once the recipient receives the message. If all delivery 
retry attempts were exhausted, a failure indication will be generated. With messages 
addressed to a group, the sender only receives confirmation that the message was 
transmitted and does not receive confirmation from any of the intended recipients. 

• When receiving a text message, the user is notified of a new message by an icon, 
display string, and an audible tone if enabled in the codeplug via the CPS. 

• Messages are received only if the radio is currently in digital mode of operation. A radio 
user should enter Scan mode to receive messages if multiple channels are being 
utilized. System planning considerations associated with data and scan are discussed in 
“System Design Considerations” on page 277 of this document. 

• A user can store up to 30 received or sent text messages at a time. The user is notified 
once the Inbox and sent folder storage becomes full. Once full, subsequent new 
messages automatically cause the oldest messages to be deleted. Messages are not 
deleted when the radio is turned off. 

• A user can store up to 30 draft text messages in the Drafts folder at a time. Once full, 
subsequent new drafts automatically cause the oldest draft(s) to be deleted. A user can 
opt to Send, Edit, or Delete the drafts in the Drafts folder. The user can opt to Save a text 
message that is being written or edited to the Drafts folder. If a high priority event causes 
the radio to exit the text message editing screen, the current text message is 
automatically saved into the Drafts folder. A draft that is sent is deleted from the Drafts 
folder and stored to the Sent folder. 

• The user can scroll through messages and select any message to read, reply to, 
forward, save or delete. 

2.4. 2. 2 MOTOTRBO Text Messaging Application 

Depending upon availability in your region, Motorola offers MOTOTRBO Text Messaging, a 
Windows PC-based application. It extends the system’s text messaging services to mobile and 
central dispatch PC users. It also provides access to an important additional service: e-mail 
messaging to radio users. The MOTOTRBO Text Messing application consists of the Text 
Messaging Server, the Dispatch Text Messaging Client, and the Mobile Text Messaging Client. 

2.4. 2. 2.1 Services Provided to a Radio User 

Leveraging on the built-in text messaging services, a user can create, send, receive, store and 
display a text message. The capabilities include the same ones available for “Built-In Text 
Messaging Service” on page 48. 
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• E-mail text messaging. A user is capable of sending and receiving text messages to and 
from any pre-configured e-mail address. These pre-configured e-mail addresses must 
be configured in the radio using the CPS and also in the Text Messaging Server. Thus, 
the user can select e-mail addresses from the radio contacts menu, and send short 
messages to any of those addresses. 

• E-mail text messaging is only available to users when the radio is configured to interact 
with the MOTOTRBO Text Messaging Server application. 

• Both the radio and the application server must be configured for e-mail. Greater detail is 
provided in “System Design Considerations” on page 277. 

2.4. 2. 2. 2 Services Provided to a Mobile Client 

A Mobile PC user is located in the field and utilizes the MOTOTRBO Mobile Text Messaging Client 
application to create and view the text messages. In MOTOTRBO systems, portable or mobile 
radios can be configured through the CPS to route text messages to an attached mobile PC user. 

The services offered by the text message mobile clients are as follows: 

• Direct Routing - The mobile client provides the ability to text message other mobile 
clients or radio users without going through the text messaging server, provided they are 
on the same channel as the originating mobile client. This is also applicable if the 
destination mobile clients or radios are scanning the channel that the originating mobile 
client is on. 

• Indirect Routing - The mobile client sends all text messages for e-mail and dispatch 
destinations through the MOTOTRBO Text Messaging Server. The Text Messaging 
Server can route the text message to a destination radio that is on a different channel. 

• Extended Messaging Length - The Mobile client application user interface contains 
two messaging composition panes; one for sending short messages to radio 
destinations and the other for long messages to e-mail, dispatch destinations, and other 
mobile clients. Text messages of up to 681 characters are supported. 

• Local mailbox storage - The mobile client provides individual access to the local 
storage of mailboxes. 

2.4. 2. 2. 3 Services Provided to a Dispatcher 

A PC-based Dispatcher utilizes the MOTOTRBO Text Messaging Client and is connected to the 
text messaging application server, either on the same machine or on the same Local Area 
Network. 

The services offered by the MOTOTRBO Text Messaging Client are as follows: 

• Full Messaging Features - The local clients provide services such as Send/Reply/ 
Forward text messages to radio users, dispatch users and e-mail destinations. The 
clients also support common mail folders such as Inbox, Outbox, Sent Items, Trash, 
Drafts, and addressing from Address Books. 

• Group Messaging - The local client is capable of sending messages to a group of 
users (system groups), in addition to Text Groups which serve as customized 
distribution lists. 

• Extended Messaging Length - The local client application user interface contains two 
messaging composition panes; one for sending short messages to radio destinations 
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and the other for long messages to e-mail and dispatch destinations. Text messages of 
up to 681 characters are supported. 

• Support for Workgroups - Workgroups allow multiple individuals to send/receive 
messages as a common dispatcher entity simultaneously. This provides a central 
storage of Inbox and Sent Items mailboxes on the server for shared access among 
users of same workgroup. 

• Presence Status - The local client provides the dispatch user with the display of the 
presence status for all radios of interest. 

2.4. 2. 2.4 Services Provided by the MOTOTRBO Text Messaging Server 
Application 

The backbone of the MOTOTRBO text message application is the server application. It is located 
on the customer’s Local Area Network (LAN). The server application sends, receives, and stores 
the text messages that involve the dispatcher clients, mobile clients, and e-mail addresses. 

The services offered by the MOTOTRBO text message server application are as follows: 

• Communication gateway - The server acts as a gateway between the radios on the 
system and the dispatcher clients. Configurable parameters within the codeplug include 
the number of retries desired, and the duration between attempts. 

• E-mail Gateway (SMTP) - The server provides the functionality of an e-mail server 
using Simple Mail Transfer Protocol (SMTP). This enables text messaging users across 
the MOTOTRBO system to communicate with an e-mail user located anywhere on the 
internet. The e-mail addresses which a radio user wishes to use must be configured on 
the server application for proper routing. Alternatively, a radio user can send a text 
message to the dispatcher requesting that the message be forwarded to an e-mail 
address. 

• Presence Notification - The Presence Service notifies a subscribing text message 
server application when a radio powers on/off, thus providing the status of radios to 
Dispatch users. When utilizing the Presence Services, the text message server 
application does not send any text messages to a user that is known to be absent from 
the system. To preserve bandwidth, such message are discarded, and a failure 
notification is returned to the original sender. Group messages do not receive a failure 
notification; group messages are sent as unconfirmed messages. 

• Central Device Management - The server provides a central configuration point for all 
text messaging client address books. 

• Authentication - The server provides an authentication gateway for dispatch users 
during login to their clients. 

• Management of Messaging Data - The server provides a central storage location for 
shared mailboxes for dispatch users and the management of concurrent access for 
these mailboxes. The archiving and backup of dispatch user mailboxes and the logging 
of message exchanges on all interfaces are also provided. 
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2.4. 2. 3 Predictive Text Entry 

Predictive text entry is now available for text messaging in MOTOTRBO software version 
R02. 10.00. Previous releases supported the multi-tap input method whereby the user repeatedly 
presses the same key to cycle through the letters for that key. For example, to type the word “the” 
using multi-tap method, the radio user presses the buttons “8-tuv”, “4-ghi” twice, and “3-def” twice. 
However, with predictive text, each key press results in a prediction, therefore they only have to 
press “8-tuv”, “4-ghi”, and “3-def, which generates “the”. 

Predictive text may take some time to master for some radio users. Therefore, there is an option to 
return to the multi-tap input method when necessary. Although once mastered, predictive text 
entry can lower the number of overall keystrokes utilized when typing a text message, making text 
messaging quicker and easier. 

Predictive text also provides additional functions: 

• Smart Punctuation - For alphabetic languages, the radio includes punctuation 
intelligently based on the input key. For example, after the radio user presses “2-abc”, 
“2-abc”, “6-mno”, “1 -,.?” and “8-tuv”, the word “can’t” is predicted. 

• Word Prediction - The radio can learn the common word sequences the radio user 
uses often. This function predicts the next word after the user enters the first word of the 
sequence that is frequently used. This can be enabled or disabled via the utilities menu. 

• Sentence Capitalization - The radio can automatically capitalize the first word of a 
sentence for alphabetic languages. This function can be enabled or disabled via the 
utilities menu. 

• Word Correction - The radio can supply alternative choices when the input word is not 
recognized by the radio dictionary. For example, if the radio user incorrectly types “thsi”, 
the radio autocorrects to “this”. This function can be enabled or disabled via the utilities 
menu. 

• Auto Accenting - Mostly used with non-English words, the radio automatically adds an 
accent to words such as “cafe”. 

• User Defined Words - A radio user can add words that are not in the standard 
dictionary, such as names, e-mail addresses, and instant messaging IDs. 

NOTE: Predictive text is only supported in color display models - the 5-line full keypad portables 
and the 4-line alphanumeric mobiles in software version R02.10.00 or later. Mobiles 
require a four-way navigation microphone with keypad. 

The following input methods are supported on the 5-line full keypad portables in software version 
R02. 10.00 or later: 

• Roman Keypad (English, Spanish, Portuguese, French, Italian, German, Polish, Turkish 
and Chinese PinYin) 

• Simplified Chinese Keypad (PinYin, Stroke) 
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• Traditional Chinese Keypad (ZhuYin) 

• Korean Keypad (Korean) 

• Cyrillic Keypad (Russian) 

The following input methods are supported on the 4-line alphanumeric mobiles in software version 
R02. 10.00 or later: 

• Roman Keypad (English, Spanish, Portuguese, French, Italian, German, Polish, Turkish 
and Chinese PinYin) 

2.4. 2.4 ETSI DMR Standard Text Messaging 

To fulfill an optional DMR Standard Text Messaging format interoperability, ETSI DMR standard 
text messaging is available in addition to (Motorola) proprietary text messaging. However, DMR 
standard text messaging has the following limitations: 

• works only for radio to radio text messaging; 

• only available in Conventional Single Site and IPSC (both local and wide area 
channels); 

• only supported on MOTOTRBO 2.0 radios (including the SL series); 

DMR standard or proprietary Text messaging can be selected through a CPS option. The radio 
can receive both DMR standard and proprietary text messages regardless of the CPS selection. 
The radio will also reply in-kind, meaning the reply will follow the received text message format 
(DMR standard or Motorola proprietary). However, while initiating a radio to radio text message, 
the initiating radio will always follow the CPS configuration (DMR standard or Motorola proprietary 
text message). 

2.4. 2. 5 ETSI DMR Tier 2 UDP/IP Header compression 

There are three choices for header compression: ETSI DMR Tier 2 UDP/IP Header Compression 
(DMR), Motorola legacy Header Compression (MSI), or do not use header compression (none). 
DMR header compression and MSI header compression are not interoperable. DMR header 
compression is supported only in the newer version radios/repeaters (R02.40.00 or later) of 
MOTOTRBO 2.0 series, and provides improved retry reliability compared to MSI header 
compression. 

Header Compression selection is configurable through CPS. Below are the recommendations for 
selecting the appropriate option. 

• Select ‘DMR’ Header Compression when using ETSI DMR Tier 2 text messaging. 



• Select ‘DMR’ Header Compression if the entire Radio and Repeater fleet supports 
“DMR”, that is, their software version is R02.40.00 or later. 

• Select ‘MSI’ or ‘none’ Header Compression if not all the radio/repeater fleet support 
“DMR”. This is for backward compatibility. Older radios/repeaters (prior to software 
version R02.40.00) only support MSI header compression or no header compression. 
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2.4.3 Location Services 




Fixed Clients (Dispatcher) 
MOTOTRBO Location Client 



Figure 2-9 Location Services 

Refer to the MOTOTRBO Network Interface Service (MNIS) and MOTOTRBO Device Discovery 
and Mobility Service (DDMS) sections for details on data communication with applications through 
a repeater network interface, instead of a control station. 

The MOTOTRBO location feature allows a dispatcher to determine the current location of a radio 
on a display map. The dispatcher can obtain the radio’s location alone (latitude/longitude) or the 
location combined with other information about the environment (horizontal speed, direction, etc.) 
that allows value-added services, such as tracking of resources. 

MOTOTRBO systems enable location services via two complementary functions. First, the 
MOTOTRBO mobile and portable radio portfolio includes models that are equipped with a built-in 
GPS receiver. The acquisition of location data is done by a GPS receiver inside the radio and is 
dependent on the GPS receiver receiving accurate signals from the earth-orbiting Global 
Positioning System (GPS) satellites. However, the GPS receiver may not work well indoors or in 
environments where the sky is largely obscured. Using the integrated data services capability of 
the MOTOTRBO system, GPS equipped mobiles and portables are able to transmit their location 
coordinates, over the radio system, to a receiving application that displays the radios’ geographic 
locations on a high resolution map. This receiving application is the second part of the system. 

NOTE: Depending upon availability in your region, Motorola offers the MOTOTRBO Location 
Services application. 

Third-party location services applications are also supported. 
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2.4.3. 1 Performance Specifications 



GPS Transmitter 


Portable 


Mobile 


TTFF (Time to First Fix) Cold Start 


< 2 minutes 


< 1 minute 


TTFF (Time to First Fix) Hot Start 


< 10 seconds 


Horizontal Accuracy 


< 10 meters 



Note: Accuracy specifications are for long-term tracking (95th percentile values > 5 satellites visible at 
a nominal -130 dBm signal strength). 



The definitions for some of the terms stated in the table above are as below: 

• Cold start - A cold start scenario occurs when the radio is first powered up, and the 
GPS receiver is attempting to acquire its first position lock. In this scenario, the GPS 
receiver only has a valid almanac stored; it does not have any valid satellite ephemeris 
data nor valid real-time clock synchronization. Almanac data is stored in a non-volatile 
(persistent) memory, and is valid for approximately one year. The GPS receiver regularly 
updates the almanac data; therefore it will always be valid unless the radio is powered 
off for more than one year. The almanac data provides a mapping of the GPS satellites’ 
position in the sky in relation to a real-time clock. 

• Hot start - A hot start scenario occurs when the GPS receiver attempts to acquire a 
new location fix after a previous fix had occurred recently. In this scenario, the GPS 
receiver has valid satellite ephemeris data, a valid almanac, and valid real-time clock 
synchronization. 

• TTFF - Time to First Fix indicates the time the GPS receiver takes to determine its first 
or subsequent position lock. This is determined largely by the time taken to download a 
full satellite ephemeris or satellite orientation packet with a data rate of 50 bits per 
second (bps), as well as, how long it takes for the GPS receiver to reach the relevant 
satellite in its Scan List. In a cold start, the Scan List includes all of the 24 orbiting 
satellites. The GPS receiver samples each satellite for a certain amount of time to 
determine if it is visible or not before moving to the next satellite. The receiver continues 
to do this until it detects a certain number of visible satellites and can determine an 
approximate location, thus helping the receiver to truncate the Scan List. In a hot start, 
the receiver already has most, if not all, the data needed to calculate its position. 
Therefore, no scanning is needed and minimal downloading is necessary to calculate 
position, resulting in a lower time to acquire a positional fix. 
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• Horizontal Accuracy - Horizontal Accuracy indicates a radius length from the reported 
point location. The latitude and longitude reported is equivalent to a point in the center of 
a circle, with the horizontal accuracy value as the radius of the circle. The true position 
should be within this location range. 

2.4. 3. 2 Services Provided to a Radio User 

When the location service is disabled, the radio does not provide any location updates to a 
location application server. An icon is displayed on the radio if the location service is enabled. The 
absence of this icon indicates that the location service is disabled. The icon shows a full satellite 
dish when good GPS signals are detected and an empty satellite dish when the radio is receiving 
poor GPS signals. 



Good Signal 


Poor Signal 


Disabled 




£ 










no icon 



The radio does not display its current location on its screen. With the exception of pressing the 
Emergency button, a radio user cannot trigger a location update to a location application server. In 
general, the radio user does not have to take any action in this process; the radio transmits the 
location coordinates automatically over the system. 

2.4. 3. 3 Services Provided to a Location Application 

For all the services, a location application server is required to send an explicit request to the 
radio. A radio does not provide unsolicited location update to a location application server. When 
the radio turns on and/or selects a properly configured channel (i.e. the previously mentioned 
“ARS Parameter"'), the radio registers with the presence service. The location application thus 
learns that this radio is on the air, and will make an explicit request for location updates if it is 
configured to track the location of the radio. 

The GPS equipped radios transmit an update of their location coordinates over the radio system in 
response to 3 service methods. 

• Single Location Update - The location application server wants to know the current 
location of a radio user. In this case, the application sends a request for a single location 
update. 

• Periodic Location Updates - Single location update is used to track the location of a 
radio user by a location application server, but is an inefficient use of air interface. 
Location tracking allows a location application server to periodically get the location of a 
radio user by sending a single location request that contains the time interval between 
updates. The radio continues to update its location periodically at the specified time 
interval until the request is cancelled by the location application server. The location 
tracking application can configure the radio to provide updates as frequently as once 
every 10 seconds. The default value is once every 10 minutes. The rate of update is 
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configurable in increments of 1 second and must be matched with the resource 
capabilities of the radio system and the needs of the end-user. This is discussed further 
in “System Design Considerations” on page 277. 

• On Emergency - A radio will send its location after the user triggers an emergency 
alarm or an emergency alarm and call request. The location update is sent only to the 
location application server which had previously sent an active location request for 
location updates from that radio upon an emergency event. This location update is sent 
by the radio only after the processing of emergency is completed. For example, for 
Emergency Alarm with Call, the location data is only sent after the emergency alarm is 
acknowledged and the initial Emergency Call is completed. This happens because the 
location data is sent as a data burst which has lower priority than the voice call. 

2.4. 3.4 Services Provided by the MOTOTRBO Location Services 

Application 

The MOTOTRBO Location Services application consists of a server called MotoLocator and a set 
of clients called Location Clients. The MotoLocator server requests, receives, and stores the 
location data of the radios. The Location Clients get the location data from the MotoLocator server 
and display the radios’ locations on a map. 

The services offered by the MotoLocator are as follows: 

• Tracked radio management: MotoLocator provides a way to edit (insert and delete) the 
list of the radios that it is currently tracking. It also allows modifying the attributes of 
those radios (e.g. a unique identifier and the name of the radio) and the parameters 
associated with the tracking of a radio (e.g. elapsed time or distance after which the 
location is sent by the radio, and content of the location data). 

• Storage of Location Data. 

• Viewing of Location Data: MotoLocator provides a user interface to view the current or 
historical location data of a radio. 

• Radio Group Management: This service allows grouping of a set of radios, so that they 
can be tracked together. 

• Resource Management. 

• Dispatcher Capability Management: This service allows configuring the radio groups 
that a dispatcher can track. 

The services offered by a Location Client are as follows: 

• Display location on a map of targeted radio/group/resource including polling and 
historical data. 

• Map Operations: This feature allows zooming, panning, and scrolling of the map on 
display. It also allows adding and editing the point of interests, and selecting the layers 
of the map for display. 

• Map Data Setup: This feature allows changing the setting of a map by allowing 
selection of the layers of the map, allowing geocoding, and customization of the search. 

• Searching: This feature allows searching the map based on the address or common 
place (e.g. hospital, or school), or point of interest. 

• Routing: This feature allows finding the shortest path between two points on a map. 
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• Geofencing: This feature allows the defining of multiple boundaries. A notice is 
provided, and a tone is heard when a resource enters or leaves any defined boundary. 
The notice indicates the device that has crossed the boundary, the boundary name (if 
the radio has more than one active boundary), and also if the device has entered or left 
the boundary. 

• Text Messaging: A Location Client integrates with MOTOTRBO Text Messaging Client 
for sending and receiving text messages to/from other resources. 

2.4. 3. 5 GPS Revert Channel 

The GPS Revert Channel feature allows system operators a configurable option to off load radio 
transmitted location updates onto a programmed digital channel that differs from the digital 
Selected Channel. This feature effectively removes Location Update traffic from the Selected 
Channel in order to free up that channel to accommodate increased voice loads and/or to enhance 
the user experience by reducing the number of channel busies during voice call requests. This 
feature also allows a large group to communicate on a single voice channel while sending location 
updates on multiple GPS Revert Channels to accommodate larger Location Update loads. This 
increases the Location Update throughput associated with radios belonging to a single group. 

Each channel programmed into the radio has a configurable CPS option to designate the GPS 
transmission channel on which it transmits Location Update messages. The CPS options for the 
GPS transmission channel are Selected, All, and None. Choosing Selected means that the GPS 
updates are transmitted on the current channel. In the case of All, a single channel must be 
chosen from the list of all channels. This chosen channel is known as the GPS Revert Channel 
and this is where GPS updates are transmitted on. It is understood that there may be instances 
when the radio is known to be out of range. In order to extend battery life, minimize time away from 
the Selected Channel, and/or to efficiently use frequency resources in these situations, the radio 
can also be configured to disable the transmission of Location Update messages on a per channel 
basis by using the selection None. It should be noted that a radio will be shown as present to the 
dispatcher when a radio is switched from a GPS enabled channel to a GPS disabled channel until 
the presence indication duration is exceeded. 

To configure the radio to support location updates, there are a few parameters that must be 
managed correctly. How these parameters interact to dictate the radio’s performance is shown in 
the table that follows. These parameters are the radio wide GPS setting that resides in the General 
Settings CPS folder, and the ARS and GPS Revert settings that are present for each channel 
defined in CPS. In this case the channel being defined is titled “Channell”. Also, in the case where 
a GPS Revert Channel (GPS1) is selected, this requires that GPS1 has already been defined as a 
channel in CPS. 
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General 
Settings: GPS 


Channels: 

Zonel 

Channell 

ARS 


Channels: 
Zonel 
Channell 
GPS Revert 


Result 


Not Enabled 


Not Enabled 


Not Selectable 


GPS Chip: Disabled 
Presence: Disabled 
Location: Disabled 


Not Enabled 


Enabled 


Not Selectable 


GPS Chip: Disabled 
Presence: Enabled 
Location: Disabled 


Enabled 


Not Enabled 


Not Selectable 


GPS Chip: Enabled 
Presence: Disabled 
Location: Disabled 


Enabled 


Enabled 


None 


GPS Chip: Enabled 
Presence: Enabled 
Location: Disabled 


Enabled 


Enabled 


Selected (Channell) 


GPS Chip: Enabled 
Presence: Enabled 
Location: TX on Channell 


GPS1 


GPS Chip: Enabled 
Presence: Enabled 
Location: TX on GPS1 



Note: Not Selectable means the setting cannot be configured as the option is grayed out. 



2.4. 3. 6 Enhanced GPS Revert Channel 

The Enhanced GPS Revert channel is an enhancement of the GPS Revert channel functionality 
that supports higher throughput and increased reliability. Similar to the former feature, a subscriber 
offloads location responses routed to a server, to a revert channel. The primary difference lies in 
the method a subscriber accesses the channel. In the GPS Revert channel feature, subscribers 
access a channel in a desynchronized manner and may therefore cause transmission collisions. 
The probability of collision increases with the number of transmissions made over the channel and 
collisions adversely affect the reliability of transmissions. 

This enhanced feature enables subscribers to access a channel in a synchronized manner, which 
eliminate collisions and allow them to use the channel efficiently. The synchronization between 
subscribers is achieved by a repeater that divides a logical channel into groups of contiguous 
bursts defined as “windows”. This allows subscribers to make reservations for these windows in 
which GPS data can be transmitted. This is a slot wide configuration. The windowed data structure 
consists of an eight minute data superframe. Within the eight minute data superframe, there are 16 
data frames, each 30-second in duration This data superframe is repeated over and over again. 
Both the data frame and superframe always have the same size for every windowed GPS Revert 
channel. 
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Within a 30-second data frame, there are windows that can be reserved by subscribers for GPS 
data transmission. The number of windows within a 30-second data frame depends on the size of 
each window. A window consists of an announcement slot in the beginning followed by bursts of 
GPS data. The diagram below illustrates the windowed data structure for a window size of six (one 
announcement + five bursts of GPS data). 



Data 

Frame 






ABABABABABA 



Single Site, encrypted example 



Announcement Data Proprietary % Rate !4 Rate !4 Rate 

CSBK Header Header Data Data Data 



0 12 3 



79 80 81 82 




Data 

Superframe 

Figure 2-10 Windowed Data Structure for a Window Size of Six 

The window size is dependent on the amount of GPS data to be sent, the privacy mode and 
header compression usage. Based on window size, the number of windows in a 30-second data 
frame is shown in the following table: 



Window Size 

(Includes Announcement Burst) 


Number of Windows 

(in a 30-second data frame) 


5 


100 


6 


83 


7 


71 


8 


62 


9 


55 


10 


50 
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The CSBK data feature introduces a 7.5-second data frame; within a 2-minute data superframe, 
there are 16 data frames. Based on window size, the number of windows in a 7.5-second data 
frame is shown in the following table: 



Window Size 

(Includes Announcement Burst) 


Number of Windows 

(in a 7.5-second data frame) 


1 


125 


2 
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A repeater’s slot that is configured with “Enhanced GPS” maintains allocations of all the windows. 
At the beginning of every window, the repeater sends an announcement containing the current 
window number, data frame and the ID of the subscriber for the next reserved window. The 
diagram below shows the scheduling of different subscribers in a window map for a given data 
superframe. 
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This windowed data structure with an 8-minute data superframe and a 30-second data frame 
allows this enhanced feature to support update rates of 0.5, 1, 2, 4 and 8 minutes in addition to 
one-time updates. 

The diagram below shows the scheduling of different subscribers in a window map for a given data 
superframe when the window size is 1 with a 7.5-second data frame. 
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This windowed data structure with a 2-minute data superframe and a 7.5-second data frame 
allows this enhanced feature to support update rates of 7.5, 15, 30, 60 and 120 seconds in 
addition to one-time updates. 

Before sending a location response, a subscriber requests a window for reservation (for one-time 
location response) from the repeater, or a set of periodic windows for periodic location responses. 
The repeater allocates window(s) (if available) and informs the subscriber in a grant message. The 
subscriber stores the window timing, reverts to the Enhanced GPS Revert channel before the 
allocated window arrives, and verifies its reservation by listening to a confirmation grant from 
repeater. The subscriber then sends its location response in the reserved window. Since 
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subscribers only send their location response in their reserved windows, collisions will not happen 
here. Hence, this methodology promotes the following benefits: 

• Support for up to 360 location responses per minute per repeater using both slots, while 
running at 90% capacity, and decrease in the number of channels and associated 
hardware needed for GPS data transmission. 

• Increased GPS reliability due to the drastic reduction of collision among subscribers 
sending GPS data. For more details on reliability based on voice loading on primary 
channel, refer to 4.4. 6. 6 “Enhanced GPS Revert - Loading & Reliability”. 

• More control over system throughput, by allowing users to choose the most appropriate 
window size, based on the location response characteristics needed. 

• For a window size of 1, support up to 1808 location responses per minute per repeater 
using both slots, while running at 90% capacity is possible. According to the memory 
limitation, 3616 radios for a 2-minute update per repeater using both slots cannot be 
supported, the maximum number of radios allowed is only 2200. If there are more than 
2200 radios, it is recommended to configure the two scheduled slots with two repeaters 
to share the loading. 

• For a window size of 2, support up to 896 location responses per minute per repeater 
using both slots, while running at 90% capacity is allowed. 

This feature is supported in repeater mode only and works in single-site, IP Site Connect, Capacity 
Plus and Linked Capacity Plus modes of operation. Only GPS data (unconfirmed only) is 
supported on the Enhanced GPS Revert channel in conventional mode (both single-site and 
IPSC). In Capacity Plus and Linked Capacity Plus modes, ARS Registration Message is also 
supported on the Enhanced GPS Revert channel. There is no support for voice or other non-GPS 
data on the Enhanced GPS Revert channel. Data from option board interface is also not supported 
over an Enhanced GPS Revert channel. 

When the CSBK data feature is enabled, the GPS and ARS data are compressed into a single 
CSBK data. Window size 1 is only supported by MNIS mode because the window announcement 
gets transmitted through the repeater’s outbound air interface, while window size 2 is supported by 
both the control station and MNIS mode. In order to ease system migration when enabling the 
CSBK data feature, a window size of 5 to 10 can be considered as it is quite compatible with the 
CSBK data feature. The size depends on the following factors: 

• The parameters that the application has requested in a location response, such as 
longitude, latitude, time, altitude, velocity, direction, and so on. 

• Whether IP/UDP headers compression is enabled. 

The table below shows the calculation for the window size with enhanced privacy enabled. 



Requested Element 


LRRP Response 
Size (bytes) 


Latitude + Longitude 


11 


Time 


6 


Request ID ** 


3 


Speed_hor * 


3 


Direction_hor 


2 
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Requested Element 


LRRP Response 
Size (bytes) 


Altitude * 


3 


Radius * 


2 



* Variable sized fields 

** Assume that Request ID value is smaller than 256. 

The following calculations assume GPS data is unconfirmed and “Compressed UDP Data Header” 
is selected in the CPS. 

For No Privacy. 

WindowSize = (( LRRPResponseSize+ 1) + 12) + 3 

For Enhanced Privacy, 

WindowSize = (( LRRPResponseSize+ l)-=- 12) + 4 

If a subscriber is out of range or its battery is dead, it will not send GPS data during its reserved 
windows, so the repeater also has a mechanism to free up the windows reserved for that 
subscriber. The repeater waits for a certain period of time before releasing the windows and this 
time is dependent on the cadence rate of the subscriber’s location request. The table below 
summarizes the amount of time the repeater waits before de-allocating windows for a subscriber. 



Update Rate 


Wait Time Before 
De-allocation (minutes) 


30 seconds 


5 


1 minute 


5 


2 minutes 


10 


4 minutes 


20 


8 minutes 


30 



In a subscriber, it is highly recommended to keep the Enhanced GPS Revert channel in the 
“Channel Pool” in the CPS. This prevents the user from accessing the Enhanced GPS Revert 
channel that may affect GPS reliability. A channel can be configured as an Enhanced GPS Revert 
channel by selecting the field “Enhanced GPS” in the channel settings. In order to send responses 
to the Enhanced GPS Revert channel, the GPS revert channel setting of the home channel has to 
be set to “Enhanced”. 

In a multisite system with roaming enabled, all sites are recommended to use the same setting 
and window size as an Enhanced GPS Revert channel. This can be configured through the 
Enhanced GPS Revert channel of the Home channel. 
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In a repeater, the CPS allows either one or both slots to be configured as Enhanced GPS. The 
window size in the repeater’s Enhanced GPS slot should match the window size in the 
subscribers. One slot can be configured for regular Data Revert and the other slot can be 
configured for Enhanced GPS Revert. The repeater CPS also allows a user to choose the 
maximum percentage of windows that will be used for periodic updates. The possible values are 
90%, 75%, 60%, and 45%. The rest of the windows are used for one-time updates and also to 
empty out queued data. When a subscriber is participating in a voice call, chances are it may miss 
its windows. This will lead to windows getting queued up in the subscriber. When this happens, the 
subscriber can make one time requests to ask for additional windows to empty out its queue. 

In a situation whereby a system has heavy voice loading, the subscriber may start to miss their 
reserved windows quite frequently. Hence, in such a scenario it is advised to run the system at 
60% or 45% capacity so the rest of the windows can be used to clear up the queued data. For 
more details on system reliability based on voice call loading, refer to 4. 4. 6. 6 “Enhanced GPS 
Revert - Loading & Reliability”. 

In an IP Site Connect system or a Linked Capacity Plus system where a revert channel is a wide 
area channel, only one repeater’s slot needs to be selected with periodic window reservation 
(90%, 75%, 60%, and 45%). For all the other peers, this value should be set to “None”. 

For all modes, it is not recommended to have any non-GPS data on the GPS Revert channel. The 
only exception is Capacity Plus and Linked Capacity Plus modes where ARS data is also 
supported on the GPS Revert channel. The system throughput is dependent on the window size 
selected for the system and the percentage of windows reserved for periodic updates. The table 
below summarizes system throughput: 



Window 


Number of Updates per Minute per Slot 


Size 


90% 


75% 


60% 


45% 


1 


904 


752 


600 


456 


2 


448 


376 


304 


224 


5 


180 


150 


120 


90 


6 


150 


125 


100 


75 


7 


128 


107 


86 


64 


8 


112 


93 


75 


56 


9 


100 


83 


66 


50 


10 


90 


75 


60 


45 



Table 4. 1 System Throughput of Different Window Sizes 



NOTE: These numbers are based on good signal conditions. The actual throughput and reliability 
may vary with RF conditions and voice call loading. For more details on loading-reliability 
relationship, see 4. 4. 6. 6 “Enhanced GPS Revert - Loading & Reliability”. 

The Enhanced GPS feature can be configured in the following manner in: 

1 .Conventional single-site and IPSC modes: 

1.1. One slot for voice, one slot for Enhanced GPS Revert 

1 .2. One slot for GPS Revert, one slot for Enhanced GPS Revert 
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1.3. Both slots for Enhanced GPS Revert 

2. Capacity Plus and Linked Capacity Plus modes: 

2.4. One slot of data revert repeater for GPS/ARS, one slot for all other data 

2.5. Both slots for Enhanced GPS Revert 

If digital voting is enabled in a system with Enhanced GPS, some of the window sizes cannot be 
used for the Enhanced GPS feature: 

• If the system is a single site system, all window sizes 1 to 2 with CSBK data feature 
enabled, or 5 to 10 may be used. Examples of such systems are Conventional Single 
Site, one site IPSC, Capacity Plus or one site LCP 

• For multisite IPSC or LCP, if the IP delay between sites is up to 60 milliseconds, the 
window size must be 1 or 2 with CSBK data feature enabled, or 7, or bigger. If the IP 
delay is up to 90 milliseconds, the window size must be 1 or 2 with CSBK data feature 
enabled, or 8, or bigger. Otherwise, the GPS data may not be transmitted nor received 
properly. 

More details in Sections 3. 2. 3.1 .5.1 “Single Site Conventional”, 3.2.3. 1 .5.2 “IP Site Connect Mode” 
and 3.2. 3. 1.5. 3 “Capacity Plus Mode”. 

2.4. 3. 6. 2 ARS Initialization Delay 

Upon power on, subscribers normally register with the Presence Notifier by sending ARS 
messages immediately. In a scenario where a user has a system with many subscribers powering 
on within a short time, there can be many collisions between ARS registration messages. To 
reduce collisions, a user can configure the maximum value of an initial random delay for ARS 
registration via the CPS. This field is called “ARS Initialization Delay” and has a range of 0 minutes 
to 4 hours with a default value of 0 minutes. 

A value of “0 minutes” defines that the ARS registration message will be sent out between 5 
seconds and 15 seconds and this feature is essentially not delayed (5 seconds to 15 seconds was 
the existing delay in ARS registration prior to R01 .07.00). If a user selects a value of “30 minutes”, 
then the subscriber randomly chooses a time between 5 seconds and 30 minutes and sends the 
ARS when this random time elapses. This randomization of time between different subscribers 
sending the ARS reduce ARS collisions at power on. 

When to use: 

• This feature can be used with Enhanced GPS to avoid collisions among large number of 
subscribers sending ARS messages in a short period of time. However, the user must 
enable “Persistent LRRP Request” in the CPS to ensure that GPS data is still sent even 
if ARS is delayed. 

• This feature can be used in any scenario where large number of subscribers power on, 
in a short period of time and delay in ARS registration message is permitted. 

When not to use: 

• This feature should not be used in situations where ARS registration message is 
immediately needed. For example; text messaging from server to subscriber may not 
work properly if this feature is enabled. 
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The table below summarizes the recommended ARS initialization delay value when ARS is sent 
on the Enhanced GPS channels in trunked systems (Capacity Plus and Linked Capacity Plus 
modes). The value varies with the window size and periodic loading percentage for the system. 



Total Number of Radios Sending ARS based on ARS Initial Delay Value 



Window 

Size 


Periodic 

Loading 

(%) 


30 

mins 


60 

mins 


90 

mins 


120 

mins 


150 

mins 


180 

mins 


210 

mins 


240 

mins 


1 


90 


100 


200 


300 


400 


500 


600 


700 


800 


75 


250 


500 


750 


1000 


1250 


1500 


1750 


2000 


60 


400 


800 


1200 


1600 


2000 


2400 


2800 


3200 


45 


550 


1100 


1650 


2200 


2750 


3300 


3850 


4400 


2 


90 


144 


288 


432 


576 


720 


864 


1008 


1152 


75 


360 


720 


1080 


1440 


1800 


2160 


2520 


2880 


60 


576 


1152 


1728 


2304 


2880 


3456 


4032 


4608 


45 


816 


1632 


2448 


3264 


4080 


4896 


5712 


6528 


5 


90 


60 


120 


180 


240 


300 


360 


420 


480 


75 


150 


300 


450 


600 


750 


900 


1050 


1200 


60 


240 


480 


720 


960 


1200 


1440 


1680 


1920 


45 


330 


660 


990 


1320 


1650 


1980 


2310 


2640 


6 


90 


48 


96 


144 


192 


240 


288 


336 


384 


75 


123 


246 


369 


492 


615 


738 


861 


984 


60 


198 


396 


594 


792 


990 


1188 


1386 


1584 


45 


273 


546 


819 


1092 


1365 


1638 


1911 


2184 


7 


90 


42 


84 


126 


168 


210 


252 


294 


336 


75 


105 


210 


315 


420 


525 


630 


735 


840 


60 


168 


336 


504 


672 


840 


1008 


1176 


1344 


45 


234 


468 


702 


936 


1170 


1404 


1638 


1872 


8 


90 


36 


72 


108 


144 


180 


216 


252 


288 


75 


93 


186 


279 


372 


465 


558 


651 


744 


60 


150 


300 


450 


600 


750 


900 


1050 


1200 


45 


204 


408 


612 


816 


1020 


1224 


1428 


1632 


9 


90 


33 


66 


99 


132 


165 


198 


231 


264 


75 


81 


162 


243 


324 


405 


486 


567 


648 


60 


132 


264 


396 


528 


660 


792 


924 


1056 


45 


183 


366 


549 


732 


915 


1098 


1281 


1464 
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Total Number of Radios Sending ARS based on ARS Initial Delay Value 



Window 

Size 


Periodic 

Loading 

(%) 


30 

mins 


60 

mins 


90 

mins 


120 

mins 


150 

mins 


180 

mins 


210 

mins 


240 

mins 


10 


90 


30 


60 


90 


120 


150 


180 


210 


240 


75 


75 


150 


225 


300 


375 


450 


525 


600 


60 


120 


240 


360 


480 


600 


720 


840 


960 


45 


165 


330 


495 


660 


825 


990 


1155 


1320 



In conventional mode, when ARS is sent on the Home channel, the table below can be used as a 
guideline to choose the delay values based on voice call loading and the number of subscribers in 
the system. 



Number of Radios Sending ARS Based on ARS Initial Delay Value 




30 

mins 


60 

mins 


90 

mins 


120 

mins 


150 

mins 


180 

mins 


210 

mins 


240 

mins 


No Voice 


300 


600 


900 


1200 


1500 


1800 


2100 


2400 


Low Voice ** 


51 


102 


153 


204 


255 


306 


357 


408 


High Voice ** 


24 


48 


72 


96 


120 


144 


168 


192 



* Refer to 4.4.2 “Voice and Data Traffic Profile" for the definitions of “High Voice”, and “Low Voice”. 

In conventional mode with CSBK data feature enabled, the table below can be used as a guideline 
to choose the delay values. When the ARS initial delay value is zero, the number of radios 
illustrated in the following table guarantees successful ARS registration of most radios within five 
minutes. According to Figure 4-1 “Number of Users per Slot versus User Experience”, a large 
number of radios can cause poor user experience for voice calls - numbers larger than 1 02 with a 
Low Voice profile and numbers larger than 48 with High Voice profile are not recommended. 



Number of Radios Sending ARS Based on ARS Initial Delay Value 




0 mins 


30 

mins 


60 

mins 


90 

mins 


120 

mins 


150 

mins 


180 

mins 


210 

mins 


240 

mins 


No Voice 


40 


600 


1200 


1800 


2400 


3000 


3600 


4200 


4800 


Low Voice ** 


15 


102 


- 


- 


- 


- 


- 


- 


- 


High Voice ** 


10 


48 


- 


- 


- 


- 


- 


- 


- 



Refer to 4.4.2 “Voice and Data Traffic Profile” for the definitions of “High Voice”, and “Low Voice”. 
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2.4. 3. 7 Data Revert Channel 

A Capacity Plus system extends the “GPS Revert Channel” feature to the “Data Revert Channel” 
feature. This feature is available only in Capacity Plus and Linked Capacity Plus modes as a 
configurable option. The Data Revert Channel feature allows system operators to offload all data 
messages from radios to a Server (e.g. registration messages, location responses, text messages 
to the Server, and their over-the-air acknowledgements, etc.) onto programmed digital channels 
(called Data Revert Channels). Data messages (including their over-the-air acknowledgements) 
from radio-to-radio and from the Application Server to radios are always sent over the Trunked 
Channels. 

The Data Revert Channel feature is optional. In the absence of this feature, data messages are 
sent over the Trunked Channels. This feature should be used when there is a need to reduce data 
traffic from the Trunked Channels. Data Revert Channels will free up the Trunked Channels and 
the Trunked Channels can accommodate increased voice loads. This also enhances the user 
experience by reducing the number of busy channels during voice calls. 

Data Revert Channels are exclusively used by the system for transporting data packets. They are 
not used for voice communication. As Data Revert Channels offload most of the data 
communication from the Trunked Channels, they facilitate more voice communication over these 
channels. Data Revert Channels are especially useful for transporting location responses. 

Each channel programmed into a radio has a configurable CPS option to designate the GPS 
transmission channel on which the radio transmits Location Update messages. The CPS options 
for the GPS transmission channel are Trunked, Revert, and None. Choosing Trunked means that 
the data messages to the Server are transmitted on the Rest Channel. In the case of Revert, data 
messages to the Server are transmitted over one of the revert channels that are programmed into 
the subscriber. There may be instances when the radio is known to be out of range. In order to 
extend battery life, minimize time away from the Rest Channel, and/or to efficiently use frequency 
resources in these situations, the radio can also be configured to disable the transmission of data 
messages on revert channels by using the selection None. 

To configure a radio to support data messages, there are a few parameters that must be managed 
correctly. How these parameters interact to dictate the radio’s performance is shown in the table in 
section 2. 4. 3. 5 “GPS Revert Channel”. 



2.4. 3. 8 GPIO Triggered Event Driven and Distance Driven Location 

Update 

GPIO Triggered Event Driven Location Update is triggered by the radio’s GPIO status change. 
The location information, timestamp and the GPIO Pin Status are combined as one location 
update. Therefore it’s easy for the location application to know when and where a GPIO Pin status 
change is triggered. 

Distance Driven Location Update is triggered when the distance traveled by a radio from the last 
update exceeds specific values defined in the location server application. Via this feature, the 
number of location updates over the air can be reduced when a radio is not moving or moving 
slowly. 

Both features are for MOTOTRBO 2.0 radios only (excluding the SL series) 
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2.4.4 Telemetry Services 

The MOTOTRBO radios incorporate telemetry functionality that is only supported in the digital 
mode of operation. Both the MOTOTRBO portable and mobile radio support General Purpose 
Input/Output (GPIO) lines on the radio accessory connector. 

With this telemetry functionality, the originating radio can send a telemetry command to another 
radio. Sending the telemetry command can be triggered either by GPIO pins or a programmable 
button. In either case, the telemetry command can be sent out on the “normal traffic” channel (e.g. 
the selected channel for single site conventional systems). Alternatively, in firmware versions 
R01.08.00 and R01.08.10, if the telemetry command is triggered by a programmable button, the 
telemetry command can be sent out on a CPS configured telemetry channel that is selected from 
the “Channel Pool” or visible zone channels. 

NOTE: When sending the telemetry command on the CPS configured telemetry channel (that is, 
not the “normal traffic channel”), neither preambles nor retries are used. To avoid missing 
the telemetry message, it is recommended for the receiving radio not to scan other 
channels, when listening on the telemetry receiving channel. 

NOTE: Regardless of whether the home channel is analog or digital, when the telemetry revert 
functionality is initiated via predefined buttons, the radio leaves any ongoing call and 
initiates the telemetry command transmission on a digital revert channel. 

Telemetry commands instruct GPIO pins on the target radio to be set, clear, toggle or pulse. The 
telemetry commands can also be used to query the status of GPIO pins at the target radio. 

At the receiving end, the basic built-in telemetry functionality allows the target radio to translate the 
received telemetry command and to trigger GPIO action. It also enables the target radio to display 
a programmed Text Status Message or act on a telemetry command received from the originating 
radio responding to an event at the originating radio's GPIO pins. The Telemetry Text Status 
Message is provisioned in the source telemetry radio and is displayed as a popup alert at a target 
radio via the telemetry application. Since the Telemetry Text Status Message is not sent as a 
standard text message, it is not saved in the Inbox or indexed. Furthermore, its target can only be 
another radio since it must be received and processed by the telemetry application within the 
radio. 

It is possible for the message to be forwarded to an external computer connected to the radio, or 
the option board, where a customer supplied application could monitor and take an action. 
MOTOTRBO provides a telemetry interface for third-party telemetry applications. 

Telemetry over-the-air signaling utilizes the data service similar to the way that text messaging 
works. It can co-exist with voice and text messaging. If telemetry messages are expected to occur 
often, for example 30 radios sending telemetry once every 5 minutes, this may affect performance 
of other services on the channel. This should be taken into consideration when determining the 
data load versus quality of service of a channel. 

2.4.4. 1 Physical Connection Information 

The MOTOTRBO portable offers three GPIO pins, and the MOTOTRBO mobile offers five GPIO 
pins for telemetry. These GPIO pins can be set to high or low, toggled, or pulsed for a configured 
duration. A pin can be configured to be active high or active low. It is recommended to use an AC- 
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powered MOTOTRBO mobile for most extended telemetry applications. Motorola does not 
currently offer external hardware for telemetry configuration. 

The GPIO lines have a 4.7k ohm pull-up resistor tied to a regulated 5 V DC supply within the mobile 
radio. The regulated supply remains on as long as power is supplied to the mobile, even if the 
mobile is turned off so the pull-ups are active even when the radio is off. 

When configured as input, the voltages of the GPIO lines should be within the range of 0 V DC to 
5.5 V DC . 



• 0 V DC to 0.8 V DC are interpreted as low level 

• 2.2 V DC to 5.5 V DC are interpreted as high level 

When configured as output, the GPIO will be able to source a current of 1mA maximum at the 
following levels: 

• 4.7 V DC to 5.5 V DC for a high level 

• 0 V DC to 0.8 V DC for a low level 

2.4.4. 2 Telemetry Examples 

See section 3.2. 1.1. 2 and section 3. 2.2. 1.2 for diagrams and descriptions of the following simple 
telemetry examples in both direct and repeater mode. 

• Send Telemetry Command from Radio to Another Radio to Toggle an Output Pin 

• Send Telemetry Message from Radio to Another Radio when Input Pin State Changes 

• Send Telemetry Command to Toggle an Output Pin from Radio to Another Radio when 
Input Pin State Changes 
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2.4.5 Data Precedence and Data Over Voice Interrupt 

Data applications on the internal option board, or running on an attached PC, are able to request 
priority treatment of data messages, and Data Over Voice Interrupt independently. To facilitate this, 
the data application designates the precedence of each data message as being Immediate, 
Priority, or Routine. When the radio receives a data message for transmission from an internal 
option board or attached PC application, the radio determines the precedence requested for the 
data message, and processes the data message accordingly. 

The use of the precedence designators can be summarized as such: 

• Immediate precedence is used to place data near the top of the queue and request the 
Data Over Voice Interrupt feature. 

• Priority precedence is used to place the data near the top of the queue without 
invoking the Data Over Voice Interrupt feature. 

• Routine precedence is used to place the data at the bottom of the queue. 

Immediate precedence is used to automatically clear the channel of voice calls by using the Data 
Over Voice Interrupt feature prior to beginning the data transmission. This capability departs from 
the typical behavior of a radio system, which normally gives priority to voice calls over pending 
data calls. Depending on the radio’s CPS configuration, the radio user whose transmission was 
interrupted may or may not receive a Talk Prohibit Tone until the user releases the PTT. 

For the Data Over Voice Interrupt feature to operate consistently, all radios using the channel 
should be provisioned with the ability to be interrupted. If some radios are provisioned without the 
ability to be interrupted (e.g., normally desirable for a supervisor’s radio), then those radios’ 
transmissions cannot be interrupted, and the data message will be placed near the top of the data 
queue (behind any existing queues for Immediate precedence data messages). When Immediate 
precedence is designated and a data (or control) transmission occupies the channel, the radio 
must wait for the channel to become clear before initiating the data transmission. 

Priority precedence is used to ensure that the data message is transmitted before any Routine 
precedence data messages, and after any existing Immediate precedence data messages. 
Priority precedence does not use the Data Over Voice Interrupt capability. When either Priority or 
Routine precedence is designated, the radio must wait for the channel to become clear before 
initiating the data transmission. 

NOTE: The Data Precedence and Data Over Voice Interrupt features do not need to be configured 
in the radio or repeater via the CPS because these features are always available. 

For more information on the Data Precedence and Data Over Voice Interrupt features, please refer 
to the MOTOTRBO Option Board ADK Development Guide on the MOTODEV Application 
Developers website. 

https://mototrbodev.motorolasolutions.com 
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2.5 Scan 

MOTOTRBO supports scanning of analog voice, digital voice, data, and digital signaling through a 
repeater or directly from another radio. MOTOTRBO radios scan channels or groups, or both. In 
Capacity Plus and Linked Capacity Plus modes, it scans the groups only. 

When scanning channels, the radio continuously searches a list of channels for activity of interest. 
When activity of interest is found, the radio stops and switches to that channel. When finished, the 
radio continues scanning the channels in the list. 

The set of channels to be scanned (or scan members) are determined by a configured Scan List. A 
radio can have multiple Scan Lists, and each channel in a radio can be associated with a different 
Scan List. Scan Lists can contain only analog channels, only digital channels, or a mixture of both 
analog and digital channels. Once Scan is started, the radio scans through each Scan member of 
the associated Scan List for the selected channel. 

The CPS allows a user to create, edit, or delete Scan members in a Scan List, as well as associate 
a Scan List to a channel. The user can start or stop Scan, and also add or remove Scan members 
of a Scan List using the radio’s interface. Changes to the Scan List made via the radio front panel 
user interface are permanen, that is, not affected by power cycle*. Note that Scan and Roam are 
mutually exclusive on a channel within CPS. 

NOTE: *This is different from the other supported feature - Nuisance Channel Delete: A channel 
with unwanted activity is called a Nuisance Channel. The user can remove a Nuisance 
Channel from the Scan List temporarily by using the Nuisance Channel Delete feature. 

When the radio is scanning, and it detects a digital Scan member in its Scan List, it looks for 
transmissions targeted towards the group(s) associated with that channel. The radio also looks for 
transmissions targeted towards itself (e.g. Private Calls or signaling commands). The radio can be 
configured such that replies that occur within a specified duration is transmitted to the same group 
and channel (this reply is called talkback). If the reply occurs outside of this duration, it is 
considered a new transmission. 

There are also options for where new voice transmissions (outside of the previously mentioned 
duration) are transmitted while scanning. Voice can be configured to transmit on the selected 
channel (the channel from which Scan was started), another predetermined channel, or on the last 
landed channel for voice (the last channel that Scan “locked-on-to”). Data and digital signaling are 
always transmitted on the selected channel. The last landed channel is not updated for data and 
digital signaling. 

Priority levels can also be configured for members of a Scan List. There are three levels of priority 
within a Scan List - Priority-1, Priority-2, and Non-Priority. The Priority-1 and Priority-2 channels 
are scanned more often than the Non-Priority Scan members. Priority Scan is available with any 
mix of analog, digital, talkaround or repeater channels. 

The Scan List can be configured to have one Priority-1 member and one Priority-2 member; the 
remaining are considered Non-Priority. When scanning, these priorities affect the order of 
scanning. The following represents the scan order of Scan List: Priority-1 , Non-Priority-1 , Priority- 
2, Non-Priority-2, Priority-3, Non-Priority-3, etc. However, the radio may reorder Non-Priority scan 
members in order to optimize the efficiency of the scan. 
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In the CPS, there are two parameters associated with Scan Lists - Set/Clear Priority-1 and Set/ 
Clear Priority-2. These are used to mark a Scan List member as Priority 1 and Priority 2; unmarked 
list members are “non priority”. 

While scanning, the radio can accept data (e.g., text message, location, telemetry, or terminal (PC) 
data). However this is only applicable if the data is received on its selected (home) channel. 

NOTE: In MOTOTRBO radios with software versions R01. 04.00 or later, various enhancements 
were made to the scan engine to improve scanning performance. This has caused some 
features, such as scanning for Group Text Messaging and Emergency Alarms, to no longer 
be backward compatible with older software versions. All equipment must be upgraded for 
these features to perform correctly. 

2.5.1 Priority Sampling 

When scanning, if some activity of interest is found, the radio stops and switches to that channel. If 
the activity of interest is incoming data addressed to the scanning radio, an individual voice call, or 
it is on a Priority-1 scan member, scanning completely stops for the duration of the call. But if the 
activity is a voice Group Call on a Priority-2 or a Non-Priority scan member, the radio continues to 
periodically scan higher priority scan members. 

For example, if the radio is receiving voice on a Non-Priority scan member, then the Priority-1 and 
Priority-2 scan members are scanned periodically. In this case, the order of scan will be: Priority-1, 
Priority-2, Priority-1, Priority-2, etc. If the radio is receiving voice on a Priority-2 scan member, then 
only the Priority-1 scan member is scanned periodically. If a transmission of interest is found on 
the higher priority member, the radio switches to that member to monitor the transmission. If it is 
not of interest, it returns to the previously monitored member. Priority Sampling does not occur 
when transmitting. 

Because the radio is currently receiving voice, leaving the current scan member to scan a higher 
priority member will cause the radio to temporarily leave the current transmission. This causes an 
audio hole in received audio that is being played through the radio’s speaker. Thus, the intervals 
during which the radio samples the higher priority members, essentially, becomes the audio holes 
that are introduced into the currently monitored voice. If there are two priority channels configured, 
this time is how often a sample is taken of either one. Therefore, one particular channel is sampled 
at a rate of double the priority sampling duration. A balance between how often an audio hole is 
introduced and how often a channel is sampled needs to be achieved to ensure that transmissions 
are not missed and to prevent introducing too many audio holes. This interval is CPS configurable 
via the “Priority Sample Time” interval parameter. Since the radio only samples at the rate of the 
Priority Sample Time, it is important to understand that if sampling for data, the Scan Preamble 
must be set to double the Priority Sample Time. 

The user experiences few to no audio holes if he is currently unmuted to a lower priority voice 
while the priority member is in the other timeslot of the same repeater. In this situation, the radio 
uses the embedded signaling in the repeater to monitor activity in the other timeslot. This should 
be taken into consideration when deciding which identifiers are assigned to which channels and 
slots. 

Not all identifiers are uniquely identified in the embedded signaling because they are compressed 
into smaller identifiers. If the system contains two or more identifiers that share the same 
compressed identifier, the radio incurs additional audio holes to validate the actual uncompressed 
identifier matches. 
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Duplicate compressed identifiers can be avoided if kept within a 256 ID range where the first ID of 
the range is an integer multiple of 256. For example if group and individual identifiers are kept 
between 0 and 255, or 256 and 511, or 512 and 767, etc., they will have unique compressed 
identifiers and no audio hole will be experienced while priority sampling the other timeslot. 

Setting a busy channel as a priority channel can cause excessive audio holes in non-priority audio 
as the radio checks each new transmission on the priority channel to determine if it is call of 
interest. If the priority channel has many short transmissions that are not of interest, the radio will 
be forced to incur at least one audio hole for each. Therefore, it is recommended, that if possible, 
high priority transmissions should be isolated on channels that are not overly utilized by other 
traffic. 

2.5.2 Channel Marking 

In addition to configuring the sampling interval for Priority Sampling, MOTOTRBO offers a way to 
mitigate the duration of the audio hole itself with a feature called Channel Marking. Although 
relatively short, it does take time to determine if a transmission is of interest on a particular scan 
member. During this time, there is an audio hole in the scanned audio. 

The Channel Marking feature introduces logic that assumes that if a transmission was recently 
identified as not of interest, there is no need to fully review it at every scan interval. Additionally, if 
the type of transmission is of the same type as the transmission identified as not of interest before, 
there is a high likelihood it is the same transmission. Therefore, the radio only needs to identify the 
type of transmission taking place, which is beneficial as identifying a transmission type takes much 
less time than fully identifying if a transmission is not of interest. This assumption is made for a 
pre-determined number of times, after which, the scan member is fully reviewed again. This 
method changes the experienced audio holes from long audio holes every priority scan interval to 
one long audio hole followed by numerous short audio holes, and then another long audio hole, 
and so on. 

This feature can greatly increase audio quality while a radio is in priority sampling mode. The 
drawback to channel marking is the assumption that the target of a transmission has not changed. 
The scanning radio will not know if the target has changed until the next full inspection. The 
system should be configured in such a way using CPS parameters to achieve a balance which 
delivers improved audio quality without sacrificing too much flexibility to consistently locate new 
transmissions which otherwise would be of interest. It is recommended that Channel Marking is 
set as Enabled in most scenarios. 

However, if there is an analog signal on a digital priority channel, the radio will incur a medium size 
audio hole on every sample even if channel marking is enabled. The radio spends this time 
searching for synchronization that is not present. It is recommended that the priority traffic be 
placed on a channel that has limited analog interference (i.e. shared use). 
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2.5.3 Scan Considerations 



The ability to scan multiple channels is an advantage when a user must be aware of activity on 
numerous channels. MOTOTRBO offers the ability to scan a list of analog and digital channels 
(frequency and slot) within the same Scan List (often referred to as a Channel Scan List). This 
feature is incredibly useful when planning to migrate from analog to digital, or when a user must 
monitor multiple repeater frequencies and slots at the same time. When operating in digital, 
MOTOTRBO also provides the ability to scan multiple groups on a channel (slot). This is often 
referred to as a Group Scan. 

A Group Scan is an optimized way to scan for multiple groups on the same channel (slot). The 
radio monitors the channel from either the repeater or directly from another radio to determine 
which group is currently transmitting. If the group transmitting is one specified in the Group Scan 
List, the radio will stop and listen. The radio is allowed to talkback to the group for the duration of 
the call hang time. This call hang time overrides the TX Contact Name setting of the channel. 
Because only one call takes place on a channel (slot) at any given time, the scanning radio will not 
miss a transmission of interest, regardless of the length of the group list. A Group Scan is 
configured by creating a group list and adding groups already in the Contacts folder. This group list 
can then be selected as the RX Group List of a particular Channel. The Group Scan does not have 
the advanced features and configuration options of a channel scan. For example, once configured 
via CPS, the Group Scan cannot be turned on or off and members cannot be added or removed. 
Furthermore, the configurable scan options (Scan Hang time Timer, Talkback, etc.) do not control 
the Group Scan. The Group Scan should be used in simple systems where no advanced scan 
options are required. If advanced scan options and features are required, a Channel Scan should 
be configured instead. 

In Capacity Plus and Linked Capacity Plus modes, MOTOTRBO radios only support Group Scan. 

• All idle radios can perform a Group Scan at the start of a call. A call always starts on the 
Rest Channel and all idle radios are on the Rest Channel. 

• At the end of a call, the participating radios are informed about the ongoing calls, 
allowing them to perform a Group Scan. 

• When a radio powers on or when it comes into coverage, it searches the channels and 
joins a call of interest (if any). If all the channels are busy, then a radio may not join an 
ongoing call of interest. 

A Channel Scan will scan a list of different channels within a system - analog or digital. A Channel 
Scan is different from a Group Scan since the radio must change frequencies and sometimes even 
modulations (analog to digital) in order to scan for activity. Unlike a Group Scan where only one 
call occurs at any given time, when scanning different channels (analog or multiple digital slots), 
there can be calls taking place on any or all of the channels. Because the radio cannot be 
everywhere at once, there is a possibility that the radio will miss a transmission of interest. 
Because of this, it is recommended that the number of channels in a Channel Scan List is kept to a 
minimum. The larger the Scan List, the more likely a user will miss, or join late, a transmission of 
interest during busy times. 
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2.5.3. 1 Scanning and Preamble 



Since data and digital signaling messages are typically shorter in duration than voice 
transmissions, it can be difficult for a scanning radio to detect such messages. This is especially 
true as the number of Scan List members increases because the amount of time between a 
scanning radio’s repeated visits to a particular Scan List member increases, making it less likely to 
be on the channel at the exact moment that the data or digital signaling message begins. Another 
factor is the amount of activity on each Scan List member; basically, the more active each Scan 
List member is, the more likely that the radio is suspending its scan operations to receive on each 
of those Scan List members, further increasing the likelihood that the radio will not receive the data 
or digital signaling on another Scan List member. To improve the likelihood of receiving data and 
digital signaling messages, the duration of these message types can be extended by preceding 
the message with special preamble signaling. The amount of preamble signaling to use can be 
configured into the initiating radio and the amount of preamble to use is dependent upon the 
number of Scan List members in the target radios’ Scan List and whether priority scan is being 
used. Since this added signaling increases the amount of airtime used for data and digital 
signaling messages, there is a trade-off between increased channel loading and increased 
likelihood of receiving data and digital signaling messages while scanning. 

Suggested guidelines for the amount of preamble duration to use with Scan Lists not using priority 
is provided in the following table. Scan preambles are not required for Capacity Plus and Linked 
Capacity Plus modes. 





Number of Analog Scan List Members 


0 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


16 


Number of Digital Scan List Members 


0 


- 


- 


480 


480 


480 


720 


720 


720 


960 


960 


960 


960 


1200 


1200 


1200 


1440 


1440 


1 


- 


- 


720 


720 


720 


960 


960 


960 


960 


1200 


1200 


1200 


1440 


1440 


1440 


1440 




2 


480 


720 


720 


960 


960 


960 


960 


1200 


1200 


1200 


1440 


1440 


1440 


1680 


1680 






3 


720 


960 


960 


960 


1200 


1200 


1200 


1200 


1440 


1440 


1440 


1680 


1680 


1680 


- 






4 


960 


960 


1200 


1200 


1200 


1200 


1440 


1440 


1440 


1680 


1680 


1680 


1680 










5 


960 


1200 


1200 


1200 


1440 


1440 


1440 


1680 


1680 


1680 


1680 


1920 












6 


1200 


1200 


1440 


1440 


1440 


1680 


1680 


1680 


1680 


1920 


1920 














7 


1200 


1440 


1440 


1680 


1680 


1680 


1680 


1920 


1920 


1920 
















8 


1440 


1680 


1680 


1680 


1920 


1920 


1920 


1920 


2160 


















9 


1680 


1680 


1920 


1920 


1920 


1920 


2160 


2160 




















10 


1680 


1920 


1920 


1920 


2160 


2160 


2160 






















11 


1920 


1920 


2160 


2160 


2160 


2400 
























12 


1920 


2160 


2160 


2400 


2400 


























13 


2160 


2400 


2400 


2400 


- 


























14 


2400 


2400 


2640 


- 


- 


























15 


2400 


2640 




- 


- 


























16 


2640 


- 


- 


- 


- 












- 




- 











The preamble duration should be increased when Scan List members tend to carry lots of traffic or 
long transmissions. If no radios in the system will use the scan feature, then the amount of 
preamble may be set to zero. 

The preamble duration should be increased when priority scan is being used because the priority 
channels are scanned more frequently in a full scan cycle. The preamble duration should also be 
increased when the selected channel or DTC is a dual capacity direct mode channel because the 
scanning radio needs to scan the beacon monitoring channel. The following table suggests 
guidelines for the amount of preamble duration to use, with or without a dual capacity direct mode 
selected channel or DTC in a digital-only Scan Lists using priority. 
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Number of Priority Members 






Without DCDM DTC/Selected Channel 


With DCDM DTC/Selected Channel 






0 


1 


2 


0 


1 


2 




0 


- 


- 


- 


- 


- 


- 




1 


- 


- 


- 


- 


- 


- 




2 


480 


480 


480 


960 


960 


960 


S£ 

0 


3 


720 


960 


960 


1200 


1440 


1200 


-Q 

E 


4 


960 


1200 


960 


1440 


1920 


1440 


0) 

2 


5 


960 


1440 


1200 


1680 


2640 


1920 


</) 

□ 


6 


1200 


1680 


1440 


1920 


3120 


2640 


c 

TO 


7 


1200 


1920 


1680 


2400 


3840 


3120 


O 

CO 


8 


1440 


2400 


1920 


2640 


4320 


3840 


75 

+* 

D) 


9 


1680 


2640 


2400 


2880 


4800 


4320 


Q 

M- 


10 


1680 


2880 


2640 


3120 


5520 


4800 


O 

l_ 

Q) 

Si 

E 


11 


1920 


3120 


2880 


3360 


6000 


5520 


12 


1920 


3360 


3120 


3840 


6720 


6000 


3 


13 


2160 


3840 


3360 


4080 


7200 


6720 




14 


2400 


4080 


3840 


4320 


7680 


7200 




15 


2400 


4320 


4080 


4560 


8400 


7680 




16 


2640 


4560 


4320 


4800 


8640 


8400 



If data and digital signaling is not carried on any of the non-priority channels and is only carried on 
one of the priority channels (which must be the selected channel for data messages), then the 
amount of scan preamble to use can be as specified in the first row of the Priority Scan table, 
above, regardless of the number of non-priority Scan List members. 

2. 5. 3. 2 Channel Scan and Last Landed Channel 

A Channel Scan can be configured by selecting a group of already configured channels within a 
radio using the CPS, and adding them to a Scan List. Each channel is then configured to use this 
Scan List of channels. When scan is activated on a channel that contains a Channel Scan List, the 
MOTOTRBO radio checks for activity on each of the channels on the list. 

While scanning a digital channel for activity, all Groups specified in the channel’s RX Group List 
will be monitored. However if the radio is configured with a Channel Scan that contains channels 
that are configured with a RX Group List (a Group Scan), then only the Last Landed Channel is 
remembered by the radio, not the Last Landed Channel and Group. This means that voice 
transmissions are transmitted on the TX Call Member configured for the channel that was the Last 
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Landed Channel, not the Group in the Receive Group List of channel that was the Last Landed 
Channel. Note that if a transmission is made within the call hang time of the scanned transmission, 
it will be targeted towards the landed channel and group. If it occurs after the call hang time has 
expired, it will be targeted towards the TX Call Member. 

When using the Last Landed Channel option, it is recommended for each group to have its own 
configured channel. This way there is only one group associated with a channel, essentially 
making the Last Landed Channel and the Last Landed Group the same. 

2. 5. 3. 3 Scan Members with Similar Receive Parameters 

When adding members to a Scan List, it is important to be conscious of the differences and 
similarities between their receive parameters. A Scan List that contains scan members with the 
same receive parameters but different transmit parameters may result in misdirected reply 
transmissions. This is best explained by first describing the simplest example of such a scenario. 




Figure 2-11 Misdirected Response while Scanning 



In this example, a Scan List contains two scan members, Channel 1 and Channel 2. Channel 1 is 
an analog channel configured for carrier squelch with a receive frequency of FI and a transmit 
frequency of F2. Channel 2 is an analog channel configured for carrier squelch with a receive 
frequency of FI , but with a transmit frequency of F3. A Scan List such as this implies that there is 
a repeater that is transmitting on FI and receiving on F2, and another that is transmitting on FI 
and receiving on F3 (See Figure 2-11 “Misdirected Response while Scanning”). Since the radio 
only listens and qualifies using the receive parameters while scanning, the scanning radio could 
monitor a transmission from either repeater on either scan member. It does not know if it has 
actually landed on the correct channel or not. It only knows that the receive parameters have been 
qualified for the current channel being scanned. In other words, it does not know if the transmit 
parameters of the channel it has landed on matches the receive parameters of the radio that is has 
monitored. If the radio has landed on the wrong channel, when the radio user replies, the radio will 
transmit on the wrong frequency. The result will be a misdirected reply about half the time. This 
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scenario can be avoided by making at least one of the receive parameters unique. In an analog 
system, this could be done with the use of PL or DPL. In a digital system, this can be done by 
using a unique color code or unique group per channel. This will allow the scanning radio to only 
“land” on the channel where all receive parameters match and therefore properly direct the user’s 
reply. 



Similar problems can occur if one scan member has fewer qualifiers than the others. Taking the 
example in Figure 2-11 “Misdirected Response while Scanning” again, Channel 1 is still an analog 
channel configured for carrier squelch with a receive frequency of FI and a transmit frequency of 
F2. However, Channel 2 is now a digital channel configured for Color Code 1 and Group 10 with a 
receive frequency of FI and a transmit frequency of F3. The receive parameters in this example 
are different, but Channel 1 has few qualifiers. Channel 1 is configured to land on any transmission 
that breaks squelch. This means that any transmission that occurs on Channel 2 will be heard on 
Channel 1 as an analog signal. This Scan List will not only result in misdirected replies, but it also 
results in a digital transmission being played out the speaker as analog. The net result is 
undesirable sounds presented through the user’s speaker. This type of configuration should be 
avoided at all times. This could be avoided by utilizing a PL or DPL on the analog channel instead 
of only carrier squelch. 

Another similar problem occurs when the unique receive parameters between scan members are 
missing or cannot be determined. One scenario where this occurs is while scanning two slots of a 
repeater and a transmission is received directly from a subscriber on the same frequency. A radio 
in repeater mode can receive a transmission directly from a radio. However, in direct mode, slot 
numbering is not utilized. Therefore, if a radio is scanning two scan members with the same 
qualifiers with the exception of the unique slot number, when it receives a transmission without a 
slot number, either scan member will monitor it and “land”. When the user replies, the transmission 
will be returned through the repeater on whichever slot assigned to the scan member it was 
monitored on. Depending on the configuration of the direct mode radio and its proximity to the 
repeater, the transmission may or may not be monitored. This can be managed by having different 
groups configured for each slot. This ensures that each slot has unique identifiers besides just the 
slot number. However, this does not help if the subscriber in direct mode is out of range of the 





Channel 1 



Radio 2 



Figure 2-12 Misdirected Response while Scanning 
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repeater. This is why it is not good practice to transmit in direct mode in the RF range of the 
repeater. 

Generally, these scenarios can be avoided if Scan Lists are created with scan members that have 
unique receive parameters. 

2.5.4 Transmit Interrupt and Scan 

Some of the Transmit Interrupt features and scan can be used together. However, there are a few 
interactions that need to be taken into consideration, as discussed in the following paragraphs. 

Firstly, since scan is not permitted when the radio is in an emergency mode of operation, 
Emergency Voice Interrupt and scan do not have any direct interactions to consider because these 
two features are mutually exclusive. However, if a radio is in scan mode when the radio user 
initiates an emergency condition, the radio first exits the scan mode of operation, and then enters 
the emergency mode of operation (optionally following emergency revert procedures). At this 
point, Emergency Voice Interrupt could be invoked, if the feature has been configured in 
accordance with the Emergency Voice Interrupt operation as described previously. 

The second interaction to consider occurs when the radio is provisioned for both the Scan Priority 
Sampling and a Transmit Interrupt feature. Priority Sampling is temporarily suspended when a 
Transmit Interrupt request is pending. This is necessary to ensure that the radio user’s transmit 
request takes priority over the radio’s receive activities. 

Thirdly, the radio can be configured with the scan feature such that replies occurring within a 
specified duration are transmitted to the same group and channel (this reply is called talkback). A 
reply that occurs outside of this duration is considered a new transmission. 

If the radio is provisioned for Transmit Interrupt and talkback, then Transmit Interrupt is applied to 
the same group and channel, when the radio user invokes a Transmit Interrupt feature while 
receiving. If the designated transmit channel is busy and the radio is not a member of the ongoing 
call, then the Voice Interrupt request is simply denied. 

Recall the options for new voice transmissions - outside of the previously mentioned duration - 
are transmitted while scanning; include the selected channel (the channel from which scan was 
started), another predetermined channel, or on the last landed channel for voice. Data and digital 
signaling are always transmitted on the selected channel. The last landed channel is not updated 
for data and digital signaling. In the event that the channel selected for a new transmission is busy, 
a Transmit Interrupt feature may be invoked on that channel if so provisioned on that channel. 
However, the radio must additionally be a member of the call in progress for Voice Interrupt to be 
invoked. 

Finally, a radio’s interruptible voice transmission periodically stops transmitting momentarily, and 
“listens” to the channel to determine whether it is being requested to stop its transmission. When a 
radio is scanning channels and testing the channel for presence of a carrier while another 
transmitting radio is listening to the channel for Transmit Interrupt signaling, the scanning radio 
may conclude that the channel has no activity and moves on to the next channel in the Scan List. 
However, this occurrence should happen only occasionally. It is most likely that the next time the 
scanning radio visits the channel, it will not occur at the moment that the transmitting radio has 
suspended its transmission. The net result is that the time taken to detect channel activity for an 
interruptible voice transmission may increase slightly, versus uninterruptible voice transmissions. 
Since the repeater is transmitting continuously even during interruptible voice calls, this is only a 
concern when scanning channels that may contain interruptible voice Direct Mode transmissions. 
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2.6 Site Roaming 

MOTOTRBO supports the ability to automatically roam between sites of an IP Site Connect or 
Linked Capacity Plus systems. 

In an IP Site Connect system, a portable or mobile is configured with a roam list that contains a list 
of channels, each of which is one site (one repeater) of an IP Site Connect system (wide area 
system). In a Linked Capacity Plus system, the Master repeater is configured with a list of 
neighboring sites for each site. The Master repeater distributes the list to all the repeaters at the 
site. The Rest Channel repeater of a site periodically broadcasts the Rest Channels of all 
neighboring sites over-the-air. The radio searches through the list of sites and selects the one with 
the strongest signal, and identifies this site as its current home site. The radio remains on this 
home site until the signal strength has dropped below a programmable threshold or when it has 
lost communications with the home site, at which time it attempts to find a better home site. If 
available, this process takes around 60 seconds in an IP Site Connect system, and around 10 
seconds in a Linked Capacity Plus system. If a better home site is not found, it remains on the 
previous home site and continues searching. Note that roaming occurs while the user is not in a 
call. Roaming is not supported while the user is in a call. 

Automatic roaming involves scanning, which requires a radio to leave the Home channel for a 
short duration. This may cause the radio to make a late entry, or to miss a data/control call (without 
preambles). A stationary radio user may suspend the automatic roaming feature by using the Site 
Lock/Unlock features. The Site Lock/Unlock feature can be activated via the menu or a 
programmable button. An icon is shown on the radio display to indicate the status of automatic 
roaming. 

Automatic roaming uses signal strength (RSSI) to select the Home channel. The signal strength is 
not always the best indication of the reception quality, especially when co-channel interference 
exists. If poor reception is encountered while automatic roaming is on, then the user can request 
the radio to find another channel. Automatic roaming, when activated via the menu/programmable 
button, allows the user to find another channel. The radio then responds to the user on the failure 
or success of the search. The radio LED indicates when the radio is roaming. 

In IP Site Connect mode, the radio display indicates which site the radio is currently on, when the 
user enables Site Lock/Unlock via a button press. 

In LCP, the radio display indicates which site the radio is currently on, when the user presses a 
button preprogrammed as the “Site Alias”. A wide area talkgroup call is broadcasted over all the 
sites associated with the talkgroup. When a Group Call is dropped at a site due to poor reception, 
the radio roams and joins the call (as late entry) after landing on another site. This only happens if 
the site is associated with the talkgroup and the call has not ended. A Private Call is repeated over 
at most two sites. Therefore the radio can join the call (as late entry), only if the radio roams 
between those two sites. 

An example of neighboring sites is illustrated below. The Neighboring Sites List of a 'site A' should 
only identify the sites to which a radio can roam from site A. 
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Figure 2-13 An Example of Neighboring Sites 

For example, if the coverage areas of the sites are as shown in Figure 2-1 3, the Neighboring Sites 
Lists can be concluded as below: 



Site ID 


Neighboring Sites List 


1 


2 


2 


1, 3 


3 


2 


4 


5 


5 


4 



The radios can be programmed with all the six sites as neighbors to each other. However, this 
causes inefficiency and potentially slows down the roaming from one geographically adjacent site 
to another. 

The radio has two methods in which it accomplishes the act of roaming; a passive method and an 
active method. 

2.6.1 Passive Site Searching 

In IP Site Connect, the Passive Site Search method has the radio searching through a list of sites 
and selecting the one with the strongest signal. In Linked Capacity Plus, the radio searches 
through a list of neighboring sites and selects the one with the strongest signal. This method is 
utilized whenever the site is unlocked. It relies on repeater transmissions in order for the 
subscriber to determine which site has the strongest signal strength. Since it is expected that the 
radio will encounter other activity while performing the Passive Site Search, it qualifies the signal 
using the sites’ programmed color code prior to selecting it as the new home. In addition, it sorts 
the sites in the roam list according to their signal strength in order to optimize follow up roams. 
Sites that have been detected in previous roam attempts and are assumed to be near by are 
searched before those that have not been detected before. Also, while roaming, the radio inspects 
the current home site in between other sites in order to minimize the time away. This strategy 
provides priority to the last home site and minimizes missing any transmissions while performing 
the roam attempt. 

While passively roaming, the radio temporarily leaves the current home channel and inspects 
other sites to decide if a better site is available. It is important to note that since the radio is 
temporarily away from the home channel, it is possible to miss the beginning of a transmission 
(late entry). Because of this, it is not advisable or required to perform passive roaming all the time. 
Therefore, the radio should only passively search for a better site when the current home site is no 
longer desirable. If the radio is within good coverage of a site, there is no need to search for a 
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better site. In other words, the radio should only passively roam when the radio has moved far 
enough away from the site that its signal strength has degraded below an acceptable value or 
when its signal is no longer present. The signal strength threshold to initiate the Passive Site 
Search (Roaming RSSI Threshold) is configurable via the CPS. See “Configuring the Roaming 
RSSI Threshold” on page 89 for suggestions on setting the Roaming RSSI Threshold for various 
site configurations and scenarios. 

Initiating Passive Site Search and selecting sites based on signal strength works well when the 
repeater is transmitting, but the MOTOTRBO repeater does perform in a shared-use environment 
and is required to de-key when not in use. If there is no activity on a system, the Passive Site 
Search cannot detect any repeaters and therefore is unable to determine at which site the radio 
should be on. Therefore, the repeater can be configured to transmit a beacon, called a roaming 
beacon. Roaming beacons are periodic short transmissions by a repeater when the repeater is 
neither transmitting nor having interference from other systems. The duration and interval of the 
roaming beacon are programmable, in an IP Site Connect system only. 

During times of no activity, the radio utilizes the signal strength of the beacon to determine when it 
should roam and which site it should roam to. If the radio does not receive a beacon in the 
expected duration, it assumes it is out of range of the repeater or that the repeater has failed and 
tries to roam to another site. The duration of the beacon is a function of the number of sites in the 
IP Site Connect system and therefore in the roam list. The interval of the beacon is a function of 
the shared use rules of the channel and how quickly a radio is required to roam when there is no 
activity. See “Setting Beacon Duration and Beacon Interval” on page 94 for suggestions on setting 
the beacon duration and interval for various site configurations and scenarios. 

In LCP, the roaming beacon duration and interval are not configurable. The roaming beacon 
interval is five times the “lost detection beacon interval” of Capacity Plus. The duration of the 
roaming beacon, in LCP, consists of only one burst and is appended at the end of every fifth 
sequence of the Lost Detection Beacons. 

NOTE: The “lost detection beacons” are transmitted periodically by the Rest Channel repeater 
when the repeater is not transmitting. The detection of the beacon by a radio indicates that 
the radio is in the coverage area of the repeater. 

The radio does not perform Passive Site Search while: 

• transmitting, 

• receiving a call of interest, 

• in emergency, 

• in good RF coverage, 

• in talkaround (direct) mode, 

• radio disabled, 

• received call alert, 

• monitor mode, 

• microphone is off hook, 

• while in active menu, or 

• while on a channel that has a Scan List (only applicable to IP Site Connect). 
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2.6.2 Active Site Searching 

The Active Site Search method consists of the radio sending wake-up messages to each repeater 
in its sorted roam list until it finds an active site. This method is utilized when the user or radio 
initiates a transmission and the home site repeater cannot be awoken, or when the user initiates a 
Manual Site Roam. 

In most cases, the Passive Site Search determines and selects the correct site if the radio is in the 
unlocked state. It may be possible that the radio has roamed into a new site and has yet to receive 
a beacon. Note that in an IP Site Connect system, the beacon interval is usually in the range of 
minutes and it typically takes approximately a minute for a radio user to move out of range of one 
site and into the range of another. Until a new site is found, the radio considers the previous site as 
the home site. 

When the user presses the PTT or a data transmission is requested, the radio tries to wake the 
Home channel repeater. This Home channel repeater is chosen from the repeaters at the radio’s 
current home site which was determined by the Passive Site Search. For IPSC, the radio chooses 
the single repeater at its home site channel. As for LCP, the radio chooses the current Rest 
Channel repeater at its home site. The radio then tries to wake a repeater at the home site. In LCP, 
if the radio has lost the previous site and is searching for a new site, all transmissions by the radio 
fail. Otherwise, the radio tries to wake the Rest Channel repeater. 

If the repeater does not wake up, the radio repeats this process for all the sites. If a repeater 
wakes up, the radio synchronizes itself with the repeater, completes the transmission and make 
the new site the home site. If the end of the roam list is reached and a site is not found, the user 
receives a failure indication. 

This entire process of discovering and synchronizing with an active repeater increases the voice 
access time of the transmission (time from PTT to Talk Permit Tone). However, this increase only 
occurs for one transmission since the next transmission proceeds regularly on the new site. 

NOTE: Wake-up messages are always sent politely. This means that if the radio detects an 
interfering signal, the radio does not transmit a wakeup message on that roam list member. 
Instead, it continues performing an Active Site Search on the next roam list member. 

If the user requests a Manual Site Roam, be it through a button press or menu item, the radio 
actively searches for the next available site using the process described above. The Manual Site 
Roam does not necessarily find the best site, but rather allows the user to move to the next site 
that is in range and transmitting. If no site is found, a negative indication is provided to the user. If 
in direct mode, a successful site search changes the new channel found to repeater mode. An 
unsuccessful site search remains in direct mode. 

NOTE: Generally, the radio does not perform any Passive Site Search during an emergency. No 
automatic roaming is performed when the radio is reverted during an emergency. 
However, when configured to a non-revert emergency channel and with Active Site Search 
enabled, the radio will perform Active Site Search automatically whenever the RSSI of the 
repeater drops below the programmed threshold or if it no longer detects repeater 
beacons. Note that Manual Site Roam is supported while in an emergency. See 
“Emergency Revert, GPS/Data Revert, and Roaming Interactions” on page 96 for more 
details. 
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It is important to note that Active Site Search causes wake-up messages to be transmitted on each 
roam list member’s frequencies until a site is found. This may not be agreeable in some areas 
where frequency overlap and sharing is common. In order to minimize the number of unwanted 
transmissions, the radio transmits one polite wake-up message. If a radio sends frequent GPS 
location updates while out of range, the radio limits the Active Site Search to only occur once every 
30 seconds. This scenario is applicable in an IP Site Connect system only. 

If this is still not acceptable in the area of operation, the radios should have automatic Active Site 
Search disabled, the Manual Site Roam button removed, and the beacon interval should be 
configured as short as possible. This ensures that the Passive Site Search finds new sites quickly 
and the user has no method to initiate an Active Site Search. Note that if Active Site Search is 
disabled, there will be no roaming while in an emergency. 
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2.6.3 Roaming Considerations 
2.6.3. 1 Configuring a Roam List 

NOTE: This section is applicable to an IP Site Connect system only. 

When configuring a Roam List it is important to keep in mind that a system can contain more than 
one IP Site Connect system, or also known here as a wide area system. A wide area system is 
made up of one or two wide area channels. Each wide area channel is an individual voice path, in 
other words, the users on the same wide area channel monitors each other on any site. 

Figure 2-14 shows a system with 2 sites, 2 wide area systems, each with 2 wide area channels. 
Wide Area System 1, Channel 1 (WAS1 CHI) represents a wide area channel in wide area system 
1 . 




Figure 2-14 Two Wide-Area Systems , Each with Two Wide-Area Channels 

Each wide area channel should have its own roam list. The roam list should contain one logical 
channel from each site that corresponds to the wide area channel. A logical channel is defined as 
the frequency pair, color code, timeslot combination. If there are multiple personalities (CPS 
Channels) that reference the same logical channel, only one should be added to the wide area 
channel roam list. Only wide area channels should be added to the roam list. 
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The table below shows an example of the two site configuration in CPS. The colors match those of 
Figure 2-14 to help clarify. 




The roam lists are configured as shown below: 



Roam List 
#- Alias 


Personality (CPS Channel) 
# - Alias 


1 - WAS1 CHI 


1 - SITE 1 TGA 


5 -SITE 2TGA 


2 - WAS 1 CH2 


2 -SITE 1 TGB 


6 -SITE 2TGB 


3 - WAS2 CHI 


3 -SITE 1 TGC 


7 - SITE 2 TGC 


4 - WAS2 CH2 


4 -SITE 1 TGD 


8 - SITE 2 TGD 



As can be seen there are 4 roam lists required for the 4 wide area channels. Each roam list 
contains only one personality that references the desired logical channel at each site. Although not 
necessary, personalities that correspond to a site can be placed together in their own zone (or 
folder). This will help further remove the concept of site from the radio user and allow the site 
roaming feature to choose the appropriate site. If they must manually choose a site, they can 
change zones. Using the actual name of the site as the zone alias will help clarify this to the end 
user, but it is not required. Since the same group is mapped to the same dial position in each zone, 
the user will have the same group selected as they change through the sites (zones). In this 
example the personalities are aliased with the group names, but other aliases that define Site, 
Channel, or Group name can be used. If there are more than one group per wide area channel, a 
roam list can be created for each group to utilize. 
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It is important to understand that when the radio determines a new home site to be one of the roam 
list members, it will only utilize the logical channel attributes of the roam list member. The 
remaining attributes will be used from the selected personality. 

The following logical channel attributes of the home site are utilized: 

• Transmit Frequency and Transmit Reference Frequency, 

• Receive Frequency and Receive Reference Frequency, 

• Color Code, 

• Time Slot, 

• Talkaround Setting, 

• GPS Revert Channel 

• Emergency System (Including Emergency Revert Channel) 

Take specific note of the GPS Revert and Emergency Revert channels. Because physical 
channels will be different per site, the revert channels must change when the radio roams to 
another site. It is recommended that emergency settings (other than revert channel) should be the 
same for all personalities within a roam list. Otherwise the radio may perform an emergency 
differently as it moves from one site to another. 

The remaining personality attributes (Transmit and Receive Group List, Channel Access, etc.) will 
be used from the currently selected channel regardless of which site the radio is currently roamed 
to. It is good practice to make these parameters identical for personalities within a roam list so that 
the radio acts the same regardless if it roams to the personality or if the user selects the 
personality. 

2. 6. 3. 2 Scan or Roam 

When selecting a roam list for a personality to utilize, one will notice that a personality cannot 
contain a roam list and a Channel Scan List. MOTOTRBO does not currently support the ability to 
roam between sites and then scan channels at a particular site. Therefore while on a particular 
personality, a user has the ability to roam or scan channels, not both. 

2. 6. 3. 3 Configuring the Roaming RSSI Threshold 

The Roaming RSSI Threshold is a CPS configurable parameter that controls the signal strength a 
subscriber needs to reach before searching for another site. If the RSSI measurement of the 
currently determined home site is above the specified Roaming RSSI Threshold, then the radio will 
remain on that site and not roam. Once the RSSI measurement drops below the threshold it will 
begin a Passive Site Search process to find a site with higher signal strength. This parameter 
essentially controls the distance away from a site a subscriber will begin looking for another site. In 
real life environments RF coverage is seldom a perfect circle, but to simplify this explanation, 
coverage will be abstracted as a circle. 

It is important to note that while passively roaming the radio temporarily leaves the current home 
site to determine if a stronger site is available. Since the radio is temporarily away from the home 
channel, it is possible to miss the beginning of a transmission (i.e. enter the call late). Because of 
this, it is not advisable to perform passive roaming all the time. 

The setting of the Roaming RSSI Threshold is a balance between when a radio will leave one site 
and look for the next versus how often the radio will perform roam and therefore increase the 
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chances of late entry to voice calls. If the Roaming RSSI Threshold is too low, the radio will remain 
on a low signal strength home site even though there might be a stronger site available. If the 
Roaming RSSI Threshold is too high, the radio will be roaming in full coverage of a repeater and 
causing late entry when not required. Figure 2-15 shows the impact of the Roaming RSSI 
Threshold value in relationship to the good coverage line (dotted) which most system coverage is 
designed to meet. Note that the Roaming RSSI Threshold is a negative number therefore a high 
value is -80 dBm and a low value is -120 dBm. The colored area is where the radio would roam. 




The default value of the Roaming RSSI Threshold is -1 08 dBm. It can be programmed for anything 
between -80 dBm and -120 dBm. A value of -108 dBm is approximately 80% of the good 
coverage. Therefore roaming will occur in the outer 20% of coverage. The default value is 
acceptable for most configurations but may not be optimal in a some particular configurations. 
Before setting the Roaming RSSI Threshold, one must consider the customer’s site configuration. 

Consider the following four basic site configurations: 

1. Dense Overlapping Coverage (Urban) - This type of coverage consists of dense sites 
with generous overlap. This coverage type is often found in large cities or highly 
populated areas. Overlapping sites utilize different frequencies. Non-overlapping sites 
may share frequencies, but those that do share frequencies need to have different color 
codes if they need to be distinguished while roaming. This type of coverage is highly likely 
to encountered shared use on one or all of its sites. A radio user may be within coverage 
of three to four sites at a time. The time it takes a radio user to move from the coverage of 
one site to another is in the range of 10 minutes. 
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2. Isolated No Overlapping Coverage (Rural) - This type of coverage consists of isolated 
sites with little to no overlap. This coverage type is often used for isolated sites in rural 
areas, although could be used to cover a single part of a small city. Non-overlapping sites 
may share frequencies, but those that do share frequencies need to have different color 
codes if they need to be distinguished while roaming. This type of coverage is less likely 
to encountered shared use although possible. A radio user will only be within coverage of 
one site at any time. The time it takes a radio user to move from the coverage of one site 
to another is in the range of multiple hours. 

3. Corridor Coverage - This type of coverage consists of in-series slightly overlapping 
sites. This coverage type is often used for covering highways, train tracks, shore lines, or 
rivers. Frequency re-use is common in this configuration since one site only overlaps with 
its two adjacent sites. Non-overlapping sites may share frequencies, but those that do 
share frequencies need to have different color codes if they need to be distinguished 
while roaming. A radio will only be within coverage of one to two sites at a time. The time 
it takes a radio user to move from the coverage of one site to another is in the range of an 
hour. 

4. Multi-Floor Coverage - This type of coverage consists of dense extremely close sites 
with short range coverage and generous overlap. This coverage type is often used for 
covering tall buildings, or deep tunnels. Frequency re-use is not common due to the small 
coverage footprint usually implemented with in-building radiax antenna systems. This 
coverage type also often encounters quick signal strength drop offs due to the nature of in 
building coverage. Non-overlapping sites may share frequencies, but those that do share 
frequencies need to have different color codes if they need to be distinguished while 
roaming. A radio will only be within coverage of one to two sites at a time. The time it 
takes a radio user to move from the coverage of one site to another is in the range of one 
minute. 
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Reference the following diagrams. 




Figure 2-16 Dense Overlapping Coverage (Urban) 




Figure 2-17 Isolated No Overlapping Coverage (Rural) 
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Figure 2-19 Multi-Floor Coverage 

The site configuration should be taken under consideration when the Roaming RSSI Threshold is 
set. For example if the customer has a “Isolated No Overlapping Coverage” the threshold can be 
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set to its lowest value of -1 20dBm. Because there is no overlap, there is no reason for the radio to 
start roaming until well outside of the coverage range of the repeater. For extremely close sites 
with large overlaps and quick signal drop off like the “Multi-Floor Coverage”, it might be better to 
set to it to a higher value so that the radios search for stronger sites closer to the repeater. The 
following table is the suggested setting for each basic site configuration. Many radio systems will 
have a combination of site configurations so the system designer will need to take all 
configurations into consideration and choose an appropriate value. 



Site Configuration 


Recommended 
Roaming RSSI 
Threshold 


% of Outer Range 
Radio Will Roam 


Isolated No Overlapping Coverage (Rural) 


-120 dBm 


Out of Range 


Corridor Coverage 


-110 dBm 


10% 


Dense Overlapping Coverage (Urban) 


-108 dBm 


20% 


Multi-Floor Coverage 


-102 dBm 


50% 



It is important to note that the preceding Roaming RSSI Thresholds assume the outbound and 
inbound RF coverage of the system is balanced. In other words, when a radio is within good 
outbound coverage of the repeater the radio’s inbound transmission can reach the repeater. Since 
the roaming algorithm uses the outbound transmission to determine when to roam, having an 
unbalanced system can cause radios not to roam even though they can no longer reach the 
repeater. This can lead to radio transmissions that do not reach the repeater and are therefore not 
repeated. 

One method to rectify this problem is to lower the output power of the repeater. This decreases the 
outbound coverage area, but ensures that if a subscriber can hear the repeater well, it can 
respond successfully. If lowering the output power is not desirable, the Roaming RSSI Threshold 
needs to be raised higher (less negative) than the recommended values. This forces the radios to 
roam to another site within very good RF coverage of another. This value may be different for 
portables and mobiles since they have different output power and therefore different inbound 
coverage. Portables may need a higher (less negative) Roaming RSSI Threshold than mobiles. 

Also note that there is one Roaming RSSI Threshold per roam list. This means that if one site has 
an inbound outbound imbalance and another does not, it may be difficult to find the correct 
Roaming RSSI Threshold to exactly accommodate both sites. In other words if you set the 
threshold to roam correctly on the imbalanced site, it may end up roaming too early on a balanced 
site. 

2. 6. 3.4 Setting Beacon Duration and Beacon Interval 

NOTE: This section is applicable to an IP Site Connect system only. 

If there is no activity on a system, the repeaters will hibernate and the radio’s Passive Site Search 
are not able to determine the signal strength, and therefore, which site is best since repeaters are 
not transmitting. Because of this, the repeater can be configured to transmit a beacon when not 
active and there is no other interfering signal. During times of no activity, the subscriber utilizes the 
signal strength of the beacon to determine when it should roam and which site it should roam to. If 
the subscriber does not receive a beacon in the expected duration, it assumes it is out of range of 
the repeater (or the repeater has failed) and attempts to roam to another site. 
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Both the beacon duration and the interval are programmable via CPS. The beacon duration is only 
configured in the repeater, but the beacon interval is programmed in both the repeater and the 
radio. 

The duration and interval of the beacon is a function of the over-the-air shared use rules in the 
customer’s region. The beacon duration is dependant on the number of sites in the IP Site 
Connect system and therefore in the roam list. The beacon interval is dependant on how quickly 
the radio is expected to roam to and from a site when there is no activity. The minimal duration and 
interval need to be met while keeping within the shared use guidelines of the region. 

The ratio of the beacon duration and beacon interval equate to how often the repeaters transmit 
while there is no inbound radio activity, i.e. the beacon transmit ratio. This ratio is not directly 
programmed into the system, but is rather a guideline for setting the Beacon Duration and Interval. 
If on a shared use frequency the beacon transmit ratio should be kept low. The target ratio is 
between 5% and 10%. In other words, if there is a need to increase the beacon duration, the 
beacon interval must also increase in order to keep the correct ratio. 

If the beacon duration is configured too short it can be difficult for a roaming radio to detect it. This 
is especially true as the number of sites increases. As the amount of time between a roaming 
radio’s repeated roam attempts to a particular site increases, it is less likely to be inspecting the 
site at the exact moment that the beacon is transmitted. Recall that the home site is sampled in 
between other sites, which increases the overall cycle time. A user is typically within the coverage 
of no more than 4 sites at any given time, therefore even with a large roam list, most of the sites 
have no activity and can be inspected very quickly. If numerous sites have shared-use frequencies 
(i.e. interference) the radio takes longer to get through its roam list and this increases the time 
between inspections of one particular site. Note that because the roam list is sorted by signal 
strength, the nearer sites are inspected first. Alternatively, if a user is transitioning to a site that 
they have not visited lately, the first roam may take slightly longer, but once it is has been detected 
this site moves to the front of the roam list. To improve the likelihood of receiving the beacon, the 
beacon duration should be increased. It is safer to have a beacon duration longer than shorter, but 
keep in mind that if the duration is increased, the beacon interval must be increased to meet the 
beacon transmit ratio. 

The beacon interval controls how quickly a radio can roam to a site and how quickly it roams away 
from a site when there is no activity. When roaming with no system activity, a radio needs to see a 
beacon in order to roam to a new site. If the repeater beacon is sent out every one minute, the 
radio may be one minute deep into the site before it sees the site and roams to it. Similarly, when 
roaming with no system activity, a radio may be one minute outside of the site before it attempts to 
roam. The impact of this value often changes based on how quickly the users are traveling. For 
example a car driving 60 m.p.h. can cover a mile a minute and therefore will be one mile into or out 
of a site before roaming. This could be acceptable for site configurations such as the “Isolated No 
Overlapping Coverage” or the “Corridor Coverage”, but the “Dense Overlapping Coverage” 
coverage type may require a quicker beacon since it will both trigger the leaving and entering of 
sites. Note again that if the user initiates a transmission before the passive roam finds the beacon, 
the radio will attempt to wake-up the site repeater. 

A one minute beacon interval may not be an issue for users on foot unless the sites are very close 
like in the “Multi-Floor Coverage” example. In this case a user in an elevator can move between 
sites at a very high rate. A one minute interval may cover the entire duration of an elevator ride 
from the first floor to the top. Here, it is recommended to keep the beacon interval in the range of 
20 seconds. Note that a beacon transmit ratio of a 5% may not be achievable for systems with a 
high number of repeaters. In this case the designer may either decide to abandon the target 
beacon transmit ratio since in-building coverage usually does not propagate very far or have 





96 



System Feature Overview 



neighbors to interfere with, or lower the beacon duration to only cover the max number of 
overlapping sites a radio may ever see. 

The table below is the recommended beacon duration and beacon interval (8% beacon transmit 
ratio) for a varying number of sites. The default value is a 4.32 second Beacon Duration with a 60 
second Beacon Interval. 



Number of Sites in 
Wide Area System 


Beacon Duration 
(sec.) 


Beacon Interval 
(sec.) 


2 


0.72 


10 


3 


1.92 


30 


4 


3.12 


40 


5 


4.32* 


* 

o 

CD 


6 


5.52 


70 


7 


6.72 


90 


8 


7.92 


100 


9 


9.12 


120 


10 


10.32 


130 


11 


11.52 


150 


12 


12.72 


160 


13 


13.92 


180 


14 


15.12 


190 


15 


16.32 


210 



* Default Values 

If shared use is not a problem in the customer’s region, the beacon transmit ratio become less 
important and it may be desirable to increase the beacon duration and decrease the beacon 
interval past what is identified here. If the automatic Active Site Search feature is going to be 
disabled, it is advisable to lower the beacon interval as much as possible since radios will rely only 
on it to find the appropriate site. 

2. 6. 3. 5 Emergency Revert, GPS/Data Revert, and Roaming 

Interactions 

Emergency Revert and GPS Revert are specific to the current home site of an IP Site Connect 
system. Data Revert is specific to the current home site of a Linked Capacity Plus system. This is 
important since a revert channel of one site will most likely not be a revert channel of another site. 
Although it is possible to revert while roaming, roaming while reverted is limited. 



While in emergency and configured as non-revert the radio will not perform Passive Site Search. If 
Active Site Search is enabled, the radio performs an automatic Active Site Search when the RSSI 
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of the repeater drops below the programmed threshold or if it no longer monitors the repeater 
beacons (normal triggers for passive roam). This is considered as a more aggressive method to 
site search as compared to passively searching. The radio also supports the ability to trigger an 
automatic Active Site Search on transmit request by the user or automatically by the radio (GPS). 
Standard Manual Site Roam is also supported. Active Site Search can be enabled or disabled via 
the CPS. 

While reverted due to emergency, no automatic roaming occurs. This is primarily due to the fact 
that the emergency revert channels may not be on the same logical channel, and the emergency 
handlers may not be the same. It is not desirable for a user to automatically leave one emergency 
handler and switch to another without notification. 

A radio will perform an Active Site Search (using the selected personality’s roam list) when the 
emergency is first initiated if the revert channel is not available. Once on the revert channel, only 
Manual Site Roam is available. In other words, if a user enters emergency, and then roams out of 
range of the revert channel, the radio does not automatically roam even if the user presses the 
PTT. When a Manual Site Roam is initiated while reverted, the radio performs an Active Site 
Search using the selected personality’s roam list. 

When a new site is found due to a roam while in emergency, the emergency process restarts on 
the new site (similar to manually changing the dial position) if the new home is provisioned for 
revert. If the new home is not provisioned as revert, the emergency process does not restart since 
the radio never left the wide area channel. It is assumed that the original target of the emergency is 
still monitoring since the source never left the wide area channel. The radio also assumes that 
emergency handling configuration (outside of revert) is the same across the wide area channel. 
The radio reverts if the new home site is provisioned as such. If a new site is not found, the radio 
returns and remains on the original site or the site revert channel, if provisioned. Per normal revert 
rules, upon clearing the emergency the radio would return to the home site. If the radio roams to a 
site that has Emergency Disabled (or no Emergency System) then radio remains in emergency but 
does not process the emergency sequence. The user can then attempt another Manual Site Roam 
to find a site that does have emergency. 

Note that in most cases, the passive search while not in emergency should get the radio on the 
correct site and therefore when it emergency reverts, it should still be at the same site. If in Silent 
Emergency mode, no ergonomics associated with Manual Site Roam are displayed. 

When a GPS/Data Revert occurs, no automatic roaming is supported. If the GPS/Data Revert 
Channel is out of range, the data message is dropped. On return to the home channel after a failed 
GPS/Data Revert, the radio continues the Site Search using the selected personality’s roam list. 

While in emergency (initiator, not receiver) and GPS/Data Revert occurs, no automatic roaming is 
supported while reverted. If GPS/Data Revert Channel is out of range, the data message will be 
dropped. On return to an emergency revert channel in an IP Site Connect system, after a failed 
GPS revert, the radio will NOT initiate an Active Site Search since this is not supported while in 
emergency. 

See “Emergency Revert and GPS/Data Revert Considerations” on page 412 for further details on 
how Emergency Revert and GPS/Data Revert operate together. 
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In summary: 



Feature 


Passive Site 
Search 


Automatic Active Site 
Search on TX Request 


Automatic Active Site 
Search on Loss of Site 


Manual 
Site Roam 


Tactical Emergency 
(Non-Revert) 


Not Available 


Available 


Available 


Available 


Emergency Revert 


Not Available 


Only Available on 
Emergency Initiation 


Not Available 


Available 


GPS/Data Revert 


Not Available 
while Reverted 


Performed After Dropping 
the Data Message 


Not Available 


Available 



2. 6. 3. 6 Performance while Roaming 

It is important to note that roaming (not just enabled, but in the act of searching) may cause some 
minor degradations in performance. Therefore, it is important that the Roaming RSSI Threshold 
and the radio’s Site Lock be set appropriately when not mobile. These degradations are similar to 
what a scanning radio would experience. Degradation may be experienced in the following areas: 

• Late Entry to Voice Transmissions (Voice Truncation) 

• Longer Preambles required for Control Messages and Data 

• Increased setup time for Confirmed Private Calls 

• Group Call Time to Talk Permit may increase if Site Search Required 

While roaming the radio temporarily leaves the current home channel and inspects other sites to 
decide if a better site is available (similar to scan). This means that radio may not be present on 
the home site when a call starts. The home site is inspected between every other site to minimize 
the time away. This is similar to the scan ordering of a priority scan member. 

One issue that arises from this situation is that if a Group Call or unconfirmed Private Call starts 
while the target is inspecting another site, the may be a short delay before joining the call. This will 
equate to voice truncation for the target radio. 

Another issue faced will be the need for longer preambles in order for command and control 
messages, and data to be received by a radio that is currently roaming. Without an extended 
preamble, roaming radios will miss the message. 

The need for preambles also affects the setup time for confirmed Private Calls. Confirmed Private 
Calls utilize command and control messaging to setup the call. In addition, the first setup attempt 
does not utilize any preambles. This increases the setup time between radios that are not roaming. 
This means that the first setup attempt of a Private Call is not successful if the target radio is 
roaming. The radio then attempts a second time with a preamble. This second attempt will more 
likely be successful and the Private Call will continue. 

If the current home site cannot be awoken, the radio attempts to locate another site using an 
automatic Active Site Search. As the radio attempts to wake-up other sites, the user must wait. 
This increase in time will be recognized as an increase in the time from PTT to receiving the Talk 
Permit Tone. This is not expected to occur often if the beacon interval is set appropriately. 
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It is expected that the value that the roaming feature adds is worth these performance 
degradations. The Beacon Interval and the Roaming RSSI Threshold should be set appropriately 
to minimize the amount of time a radio is searching for a site. 

2. 6. 3. 7 ARS Registration on Roaming 

When a radio roams in data capable mode with the Presence Service enabled, the radio can be 
configured to automatically send ARS registration messages to the Presence Notifier application. 
This ARS registration on roaming capability can be enabled or disabled via CPS configuration, and 
is applicable in both Passive Site Search and Active Site Search. 

During Passive Site Search roaming, when ARS registration on roaming is disabled, the radio 
roams when the RSSI of the repeater roamed into is greater than the RSSI of the current Home 
channel by 0 dB. However, when ARS registration on roaming is enabled, the radio roams only 
when the RSSI of the repeater roamed into is greater than the RSSI of the current Home channel 
by 6 dB. As a result, this reduces frequent registrations on roaming. 

During Active Site Search roaming, when ARS registration on roaming is enabled, the radio 
automatically sends an ARS message to the Presence Notifier application if it roams into a site 
successfully. 

This ARS registration on roaming capability can be used by user applications to monitor which 
repeater site a radio is currently in. 

2.7 Voice and Data Privacy 

Over a digital channel, MOTOTRBO supports a way to keep communication (both voice and data) 
private. Privacy protects the information, where “protection” means that the MOTOTRBO resists 
reading of data payload or listening of voice by anybody other than the intended receivers. 

MOTOTRBO does not provide any mechanism to authenticate the radios or radio users and it 
does not protect the integrity of the messages. 

2.7.1 Types of Privacy 

MOTOTRBO offers two types of privacy mechanisms - Basic and Enhanced. Both Basic and 
Enhanced Privacy utilize Motorola proprietary mechanisms/algorithms and therefore are not 
interoperable with other vendor’s privacy offerings. 

The main differences between Basic and Enhanced Privacy are that the Enhanced Privacy 
provides higher level of protection and it supports multiple keys in a radio compared to one key in 
the case of Basic Privacy. 

The two privacy mechanisms are not interoperable. Both mechanisms cannot operate in a radio at 
the same time. This implies that either all the digital private channels support Basic Privacy or 
Enhanced Privacy. Also all the radios on a repeater must use the same privacy mode even if they 
are in different groups. In direct mode, all the radios that communicate with each other must use 
the same privacy mode. 

The software for both co-exists in a radio and repeater. While configuring a radio or repeater using 
CPS, the CPS user selects the radio-wide privacy type to be either Basic or Enhanced. 
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2.7.2 Strength of the Protection Mechanism 

The Basic and Enhanced Privacy types do not provide resistance against “replay attack” (i.e. an 
adversary intercepts the data and retransmits it) or “traffic analysis” (i.e. disclosure of information 
that can be inferred from observing the traffic patterns). 

Their protection mechanism requires a key that is shared only among the intended parties. They 
do not use any hardware-based cryptographic engine or a hardware-protected memory for storage 
of keys. 

The resistance provided by the Basic Privacy is minimal due to the following reasons: 

• The Basic Privacy uses a non-cryptographic algorithm to transform plain voice/data into 
protected voice/data. It is possible for an adversary to obtain the key by storing a few 
over-the-air voice or data packets and performing few simple mathematical operations. 

• The Basic Privacy uses 16 bit keys. A user selects a key from 255 predefined keys 
stored in the CPS. The limited number of possible keys makes it easy for an adversary 
to guess the key in-use. 

The intended use of the Basic Privacy is to stop casual eavesdropping only. 

The resistance provided by the Enhanced Privacy is significantly better than the resistance 
provided by the Basic Privacy due to the following reasons: 

• The Enhanced Privacy uses a cryptographic algorithm to transform plain voice/data into 
protected voice/data. The algorithm is the well-known ARC4. (Alleged RC4) and is same 
as RC4 1 . A cryptographic algorithm makes it very difficult for an adversary to obtain the 
key from over-the-air protected messages. 

• The Enhanced Privacy uses 40 bit long keys. A radio can store up to 16 keys and the 
Enhanced Privacy allows using different keys for different channels. The large number 
of possible keys (approximately 1 trillion) makes it difficult for an adversary to guess the 
value of a key. Note that a 40 bit long key may not provide the protection needed to 
transmit valuable data such as credit card numbers. 

• Using the same key, the Enhanced Privacy protects each superframe of voice or each 
data packet in a different and unrelated way. This increases the resistance further. 

2.7.3 Scope of Protection 

The Basic and Enhanced Privacy protect only the voice and data messages (including IP/UDP 
headers). The layer 2 voice and data headers, data response packets, and link control data are not 
protected. This means that the source and target individual ID and Group IDs are not protected. 
Control messages such as Radio Disable, Remote Monitor, Radio Check, Call Alert and the 
embedded and standalone digital signaling are also not protected. 

The protection is provided in all the operational modes (direct mode, repeater mode, and IP Site 
Connect) and through all the communication paths between the sending radio and the destination 
radio. This implies that the voice and data messages remain protected in the following situations: 



1. The name “RC4” is trademarked by RSA Security. Although “unofficial” implementations are legal, but 
the RC4 name cannot be used. 
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• Over-the-air, in direct mode; 

• Over-the-air and inside a repeater, in repeater mode; and 

• Over-the-air, inside repeaters, and over the backend network, in IP Site Connect, 
Capacity Plus and LCP modes. 

Note that the Basic and Enhanced Privacy types do not protect the voice and data messages 
between a radio and its option board or between a radio and its accessory (including a MDT). Any 
data that extends past the radio network is not protected. For example, text messages from field 
units to text message dispatchers or e-mail addresses on a network are not protected once they 
leave the destination radio (i.e. a Control Station) or the MNIS application. 

The Basic and Enhanced Privacy types protect Individual voice call, Group voice call, All system 
call, Emergency Call, and all Packet data calls (i.e. Individual, Group, unconfirmed, and 
confirmed). 

2.7.4 Effects on Performance 



Basic Privacy uses only one key, which is known to both the sender and the receiver. This 
eliminates the need to transport crypto parameters (e.g. Key Identifier) with the voice or data 
payload. A voice message, in case of Basic Privacy, neither requires any modification in the 
payload nor any additional headers. Therefore, the System Access Time and the audio quality of a 
Basic privacy protected voice is same as that of an unprotected voice. 

Enhanced Privacy uses multiple keys and a random number to ensure that the encryption data is 
different for each data message and each superframe of a voice message. This requires 
transporting crypto parameters (e.g. key Identifier, Initialization Vector) with the voice or data 
payload. A voice message, in the case of Enhanced Privacy, requires an additional header and 
replaces some of the least important bits of the voice payload with the Initialization Vector. The 
additional header increases the System Access Time except when Talk Permit Tone is enabled (in 
repeater mode) where the additional header replaces one of the normal voice headers. The 
replacement of payload bits reduces the voice quality. Note that the reduction in voice quality is 
barely noticeable. 

In the case of both Basic and Enhanced Privacy, a data message requires an additional header to 
distinguish between an unprotected data message and a protected data message. In the case of 
Enhanced Privacy, the additional header is also used to transport crypto parameter. This reduces 
the data throughput. For example, a typical protected confirmed location response takes 600 
milliseconds compared to 540 milliseconds for an unprotected one (approximately 10% loss in 
throughput). 
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2.7.5 User Control Over Privacy 

The Customer Programming Software (CPS) allows a System Installer to select the type of privacy 
(i.e. Basic and Enhanced Privacy). CPS also allows the enabling or disabling of the privacy service 
of a channel. The option to toggle the privacy capability per channel can additionally be given to 
the radio user by providing a menu entry or programmable button. Without the menu entry or 
programmable button, the radio user is essentially “locked” to the channel’s privacy setting. It is 
important to note that a user can set or reset privacy for a channel, and not for the radio. If the user 
is provided with the menu entry or programmable button, and he toggles the privacy setting, only 
the selected channel’s privacy setting is toggled and remains toggled even after the user changes 
channels or zones. Toggling the privacy setting on a channel will not affect the privacy setting on 
other channels. 

The privacy setting of a channel controls the transmit privacy setting, not the receive privacy 
setting. A radio on a privacy-enabled channel always transmits protected, while a radio on a 
privacy-disabled channel always transmits unprotected. However, the radio receives both 
unprotected and protected regardless of the channel’s privacy setting. Any time the radio receives 
a protected message, regardless of the channel’s privacy setting, the radio always tries to 
unscramble or decrypt the message. If a radio is never required to receive protected messages 
then it should be provisioned with a key that is different than the key(s) used by the rest of the 
system. Simply setting a channel to be privacy-disabled does not stop the radio from receiving 
protected messages. A radio receives a protected message correctly as long as it has the right 
key. 

Therefore, when one radio user on a privacy-enabled channel transmits, every radio, regardless of 
its channel’s privacy-enabled or privacy-disabled status, will hear the transmission clearly if their 
provisioned Privacy Key is identical to that of the transmitting radio. A radio user receiving a 
protected transmission sees the green LED blinking rapidly. The receiving radio user should 
consider changing the privacy setting to match that of the call initiator when replying. 

In case of Basic Privacy, a system utilizes only one key and if all radios are privacy capable, it is 
recommended that all radios are set to privacy enabled and equipped without the option to toggle 
the privacy settings by a radio user. Since Basic Privacy does not cause any degradation in audio 
quality, or decrease in performance, there is no reason for the normal user to switch between non- 
privacy and privacy. Removing the option to toggle the setting from the radio user will safeguard 
against any complicated privacy mismatch scenarios. 
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2.7.6 Privacy Indications to User 

It is important for a radio user to know the privacy status (i.e. enabled or disabled) of the current 
channel, and also to know if the received voice transmission is unprotected or a protected voice 
transmission. There is no privacy indication for incoming protected data transmissions. 

Prior to transmitting, a radio user should check the privacy setting of the current channel. On 
privacy-enabled channels, an icon is shown on the front panel display of the radio when the radio 
is idle. 



Privacy Status/Type 


Icon 


Enabled 


a 


Enhanced and Disabled 


a 


None 


no icon 



Upon receiving a voice transmission, the radio user can know the privacy status of the voice 
transmission by observing the blinking rate of the receive LED. When receiving a protected voice 
transmission, the LED blinks green but at a quicker rate than when receiving an unprotected voice 
transmission. 

If radio users in a call have mismatching privacy settings, but the same key, they are able to 
communicate, but the transmissions are protected in only one direction. In other words, only the 
transmissions from radios with privacy enabled are protected. 

The radio does not automatically negotiate privacy settings, or block transmissions that are not 
protected. Therefore, it is up to the radio users to monitor the privacy indications to determine if all 
the users in the call have a matched privacy setting. The radio will display the privacy setting of the 
received transmission, but will blink if it does not match the transmit mode of the receiving radio. 
When a privacy setting mismatch occurs, they should request the other members of the call to 
switch their privacy settings to match. The radio allows users to enable or disable privacy on the 
channel while on a call. 

Radio users with non-display or numeric display radio models are not able to view the icon that is 
shown on a privacy-enabled channel. Therefore, it is recommended that such users should not 
have the option to toggle the privacy setting. 

If non-display or numeric display radio users must be able to toggle between protected and 
unprotected, it is recommended that this be done by programming duplicate channels, one with 
privacy enabled and one without, and the user should use the dial position to toggle between 
protected channels and unprotected channels. For example, dial position one may be set to 
communicate with a Group in unprotected mode, and dial position two may be set to communicate 
with the same group but in protected mode. 



104 



System Feature Overview 



2.7.7 Key Mismatch 

In the case of Basic Privacy, a receiving radio assumes that the received protected transmission is 
protected using the same Key that it has, because the key identifier is not sent with the message. 
If the receiving radio does not have the same key as the transmitting radio, the receiving radio 
cannot unprotect the transmission correctly. For voice transmissions, this results in unintelligible 
audio (sometimes referred to as digital warbles) being played through the target’s speaker. For 
data transmissions, this results in an unsuccessful data message transmission. This is because 
the IP/UDP headers of a data message when unprotected using a wrong key fail to CRC check. 
On failure of the checksum, the data message is not delivered to the application. 

In the case of Enhanced Privacy, the key identifier is sent with the message and if the receiving 
radio does not have the key then it either remains muted (in case of voice message) or discards 
the data message. If the key value associated with the key identifier is different in the sender and 
receiver, due to a miss-configuration, then the voice transmissions will result in unintelligible audio 
and the data transmissions will be unsuccessful. 

2.7.8 Keys and Key Management 

In the case of Basic Privacy, a radio is capable of holding only one Privacy Key. The same key is 
used to protect and unprotect voice and data transmissions over all the channels and for all call 
types: Group Call, Private Call, All Call, or Emergency Call. 

In the case of Enhanced Privacy, a radio is capable of holding up to sixteen Privacy Keys, where 
keys are associated with channels. The relationship between keys and channels is 1:0...n. (in 
other words 1 to 0 or 1 to many) “0” means that keys may be provisioned into the radio but are not 
associated with any channel. In this case, the keys are used to unprotect a received message but 
are not used by the radio to protect a transmission. 

A Privacy Key is provisioned in a radio using a CPS. The keys are not readable, editable, or 
erasable by the radio user. Once a key has been chosen and programmed into a radio, the key 
cannot be extracted and viewed by CPS. It can only be retained or overwritten. 

In the case of Basic Privacy, a CPS user can select one of the 255 prescribed keys. These keys 
are referenced by a key index from 1 to 255. Each key index references a particular 16-bit key that 
is used for protecting over-the-air. There is no option for a “blank”, “null”, or “zero” key. In the case 
of Enhanced Privacy, the valid range for the value of a key is 1 to 1,099,511,627,774 (i.e. 
FFFFFFFFFE in hex). The key values 0 and 1,099,511,627,775 (i.e. FFFFFFFFFF in hex) are 
reserved and should not be used. 

MOTOTRBO does not support remote or over-the-air programming of keys into a radio. Keys can 
be programmed in a radio using only CPS. CPS supports loading of the value and identifier of a 
key into a radio either manually or from a protected archive file (in case of Enhanced Privacy only). 
In case of getting the keys from a protected archive file, the CPS User selects the protected file 
and provides the password. The file is unreadable without a password. The CPS is capable of 
copying key(s) from one radio's archive into another radio's archive without the user needing to 
retype the key for each radio. 

A customer may need to change one or more keys (in the case of Enhanced Privacy) with a set of 
new keys into a set of radios. Some of the reasons for changing keys are: 



Compromise of keys 
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• Security policy of the customer requires periodic update of keys 

• Loss of a radio resulting in a concern that this may lead to compromise of keys or 

eavesdropping. 

The easiest way to implement a key switchover is to gather all radios and re-program them at one 
go. But it may not always be possible to gather all the radios without seriously affecting day-to-day 
operations. 

An alternate method is to create two zones where one zone is set to unprotected while the other is 
set to “protected”. The key can be changed on the protected zone and the users shall use the 

unprotected zone until all radios have been updated. Once all radios have been updated, the 

dispatcher informs the fielded radios to switch zones. This allows users to communicate in clear 
until the all radios are provisioned, and then all the users switch keys at the same time. 

A similar zone strategy can be used to perform periodic key set changeovers. For example, when 
one zone has January’s keys and another duplicate zone has February’s keys. On the first of 
February, the users switch to the February zone. Throughout February, the January zone is 
updated with March’s keys and renamed to “March Keys”. On the first of March, the users switch, 
and so cycle starts again. This makes sure that only two months of keys are compromised if a 
radio is stolen or lost. 

2.7.9 Multiple Keys in a Basic Privacy System 

Although a radio can only use one key in a Basic privacy system at a time, a Basic privacy system 
may utilize multiple keys to sub-divide a group into a set of groups. Note that this is not a 
recommended configuration, and some considerations need to taken into account, if the decision 
is made to utilize multiple keys in a system. 

It is not recommended that Groups be sub-divided into smaller groups with the use of keys. This 
results in one sub-group of users hearing unintelligible audio (or digital warbles) when the other 
sub-group communicates. It is recommended that the users should be divided into Groups, and 
provisioned so that a user can not transmit nor receive on the other’s Group. If users with different 
keys are allowed to communicate with Basic privacy enabled, for example via a protected Private 
Call, a key mismatch will occur and unintelligible audio will be heard. Although these users with 
different keys will never be able to communicate privately, they will be able to communicate when 
privacy is disabled. 

For example, two different Groups are isolated by provisioning different privacy keys. When a user 
in each Group needs to communicate to each other via a Private Call, they must do it with privacy 
disabled. If a radio user needs to communicate with both Groups via an All Call, the radio user 
must transmit in clear mode so that both Groups can monitor. If users respond with privacy- 
enabled, the user who initiated the All Call only monitors the responses protected with a matching 
key. 

If the system is utilizing data applications and must communicate through a control station to the 
application server, all radios on a slot must have the same key or they will not all be able to 
properly communicate with the control station. For similar reasons, it is not recommended to have 
radios without privacy capability, i.e. older software versions, in the same Group as radios with 
privacy capability. Since older radios are not provisioned with a Privacy Key, the audio will be 
muted. If radios with privacy capability need to communicate to radios without privacy capability, 
they will need to disable privacy before transmitting. 
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As a general rule, it is always recommended that groups with different privacy capabilities and 
settings be placed in different Groups and on different slots. 

2.7.10 Data Gateway Privacy Settings 

Refer to the MOTOTRBO Network Interface Service (MNIS) and MOTOTRBO Device Discovery 
and Mobility Service (DDMS) sections for details on privacy configuration when the MNIS is acting 
as the data gateway. 

The privacy setting of a control station acting as the data gateway to the application server is very 
important for consistent data communications. This may even drive the privacy configuration of the 
rest of the system. 

If a system contains some privacy-capable radios and some privacy-incapable (i.e. older software 
versions) radios then the control station must be privacy capable, but configured to transmit 
unprotected. This way, outbound messages can be received and processed by the older radios 
(not privacy capable). Note that the privacy capable radios send their data protected and the 
control station will be able to decode these messages, as long as it has the proper key. 

In case of Basic Privacy, there can only be one key per channel (or slot). Since the control station 
can only contain one key, it cannot communicate privately to two different Groups utilizing different 
keys. If a Basic Privacy system utilizes multiple keys, those users must be divided onto two 
separate channels (or slots), each with their own control station utilizing the proper key. Setting the 
control station to privacy disabled will not solve this problem since incoming messages such as 
GPS or text messages may be protected using different keys and only one key can be used at the 
control station to unprotect. Therefore, although outbound messages would be functional, inbound 
messages would not be. 

If users have the ability to toggle their privacy settings, it is acceptable to have the control station 
set to either privacy enabled or privacy disabled, but only if their provisioned keys match. If the 
control station is set to privacy enabled, and the radio is set to privacy disabled, one direction of 
the data communication will be protected and the other will be unprotected. Since radios set to 
privacy disabled will receive protected, and radios set to privacy enabled will receive unprotected, 
the communication path will work. If important data is being transferred to and from the fixed 
infrastructure, it is recommended that the control station should be set to “protected”. This will 
guarantee that at least half of the data transmission will be private. Also, the system will be tolerant 
if fielded radios are set to privacy disabled. 

It is recommended that all radios including control station should have same privacy settings. If the 
privacy setting is Enhanced Privacy, then the control station should have the transmit keys of all 
the radios and all the radios should have the transmit key of the control station. 
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2.7.11 Protecting One Group’s Message from Another 

There may be a need for one Group’s voice and data to be protected against another over the 
same channel (same frequency and same slot). There may be some radio users who are 
members of one or more of the groups. In this case, if a group not only wants to protect their 
communication from intruders but also from other groups then each group should use separate 
keys for protection. 

The System Installer should make each group that need to be protected as “TX Group” for a 
personality. The relationship between a personality and a group is 1:1. The System Installer should 
associate a key to a personality. The relationship between a key and a personality is 1:1. And 
therefore the relationship between a key and a group becomes 1:1. If a radio ‘X’ wants to make a 
protected Private Call to a radio ‘Y’ and if both the radios are member of a group ‘T’ then the radio 
‘X’ goes to a personality whose “TX Group” is T. If there is no group where both the radios are 
member then it is not possible to send a protected message. 

For a protected “All Call”, the transmitting radio should go to a specific personality and the key 
associated with that personality is present in all the radios. For a protected Private Call, the 
transmitting radio should go to a specific personality and the key associated with that personality is 
present in the receiving radio. 

2.7.12 Updating from Basic Privacy to Enhanced Privacy 

It may not be possible for a System Installer to update all the radios from Basic Privacy to 
Enhanced Privacy in one session. In such cases, the System Installer instructs all the radio users 
to disable the privacy feature and operate in clear mode. When instructed, the radio users disable 
the privacy feature using the radio front panel. All the messages are transmitted in clear. 

The System Installer updates the software of radios and configures the radios for desired privacy. 
Once all the radios are upgraded, the System Installer updates the software of repeaters and 
configures them for Enhanced Privacy. The control stations acting as the data gateway should also 
be upgraded. 

The System Installer instructs all the radio users to enable the desired privacy feature. The radio 
users enable the desired privacy feature using the radio front panel. The control stations also 
enable the desired privacy. All the messages are transmitted using Enhanced Privacy. 
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2.8 Repeater Diagnostics and Control (RDAC) 

Repeater Diagnostics and Control (RDAC) allows a system administrator the ability to monitor and 
control repeaters within the system. The following services are provided: 

1. Repeater Diagnostics 

• Read Enabled/Disabled Status 

• Read Analog/Digital Status 

• Read Wide or Local Area Status 

• Read Transmit Power (High or Low) Status 

• Read Available Channels (including Currently Selected) 

• Read Inbound RSSI 

• Read IPv4 Address and UDP Port (required for connectivity) 

2. Repeater Alarm Reporting 

• Detect and Report Receiver Lock Detect Failure 

• Detect and Report Transmitter Lock Detect Failure 

• Detect and Report AC Power Failure 

• Detect and Report RF PA/System Overheating 

• Detect and Report RF Power Out 

• Detect and Report High VSWR Detection 

• Detect and Report RF PA Fan Failure Alarm (only on the MTR3000) 

• Detect and Report EEPROM Corruption (only on the MTR3000) 

• Detect and Report Low and High RF PA Voltage (only on the MTR3000) 

• Detect and Report SCM Reference Incompatibility Alarm (e.g. SCM with TCXO in 800/ 
900MHz band) (only on the MTR3000) 

• Detect and Report FRU Incompatibility Alarms (e.g. PA and exciter are incompatible) 
(only on the MTR3000) 

• Detect and Report Main Fan Failure (only on the XPR 8300/XPR 8380/XPR 8400, not 
applicable for the MTR3000) 

3. Repeater Control 

• Change Enabled or Disabled Status 

• Change Channels 

• Change Transmit Power Level (High or Low) 

• Reset Repeater 

• Knockdown Repeater 

The RDAC application can be configured to work over the network via IP or locally via USB. 

When working over the IP network, the application communicates with all repeaters within an IP 
Site Connect or Capacity Plus system using the same link establishment process that the 
repeaters utilize. Therefore, it benefits from the existing link establishment and authentication 
utilized between repeaters. All services in the list above are available through the RDAC 
application. 
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When working locally, the RDAC application connects to a single repeater via USB. All services in 
the list above are available through the RDAC application. The repeater control services are not 
available via the USB interface through the RDAC application. 

The user also has access to the repeaters external GPIO pins. External equipment (or existing 
remote adapters and desksets) can be configured to set or read the GPIO pins to allow access to 
the repeater control services as well as access to indications that a minor or major alarm has 
occurred. The access to these GPIO pins further allows the radio installer to utilize the alarm pin 
and enable/disable pin to create a redundant switch over configuration. Alarm Reporting and 
Control is available using the GPIO pins. 

Note that any combination of RDAC connected over the Network, RDAC connected via USB, or 
connections via GPIO are supported. 

The ability to change the repeater channel can be utilized to toggle channel parameters between 
predetermined settings. For example, if the repeater contains one channel that is in analog mode 
and another channel that is in digital mode, changing the channel between these channels 
essentially changes the mode from analog to digital. The same strategy can be used to toggle the 
wide area and local setting of a timeslot. One personality could be provisioned for two wide area 
channels, while the next has one wide and one local channel. Other channel parameters can be 
changed using the same strategy. 

NOTE: When a repeater in Capacity Plus or LCP mode changes to an analog mode via RDAC, 
the repeater can no longer be accessed via RDAC. 

It is important to note that many control operations require the repeater to perform a reset before 
processing the control operation. During the reset the repeater will not be able to service inbound 
transmissions from fielded radios. Also note that the repeater takes no consideration to the 
ongoing traffic when instructed to perform a control operation. In other words if a call is in progress 
(Group Call, Private Call, All Call, Emergency Call, data call, etc.) the repeaters perform the 
control operation and drop the call in progress. In addition, the IP connection between the repeater 
and the RDAC will be temporarily severed while the repeater is rebooting. The connection must be 
re-established before additional operations can be performed. This should be taken into 
consideration before performing any control functions on an active repeater. 

In addition to the repeater reporting alarms to RDAC application and setting the GPIO alarm pins 
accordingly, it is important to note that it also takes action when major alarms are received. The 
repeater will perform a reset after a major alarm is reported as an attempt to clear the alarm. If the 
alarm is not clear after reset it will reset again. This will continue until the alarm is cleared or the 
repeater is locked (3 major alarms). Once 3 major alarms have been reported, the repeater will 
enter the Locked state and set the Major Alarm Pin. At this time all the LEDs on the Repeater front 
panel will be solid. While in the locked state, the repeater will not service any calls over-the-air. 
The RDAC application will display the locked state and have the ability to retrieve logs. 

In order to exit the locked state, the repeater must be read and written to with the CPS to reset the 
major alarm counter. This is automatically done when CPS writes a codeplug to the repeater. Note 
that 3 major alarms almost certainly means that there is a hardware problem that should be 
addressed prior to clearing the locked state. 
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All MOTOTRBO repeaters (XPR 8300, XPR 8380, XPR 8400, MTR3000) support the following 
alarms: 



• Rx Alarm 

• Tx Alarm 

• Fan Alarm 

• Power Alarm 

• Temp Alarm 

The following alarms are additionally supported by XPR 8300, XPR 8380, XPR 8400 and 
MTR3000 repeaters only: 

• Tx Power Alarm 

• VSWR Alarm 

NOTE: Revision A UHF B1 and VHF repeaters do not support any RDAC alarms. These alarms 
were only supported on Revision B and later, hardware. 

Alarms are categorized as shown below: 

• Major Alarms - Major alarms indicate hardware failures that prevent the repeater from 
functioning normally. 

• Minor Alarms - Minor alarms are warning alarms causing the repeater to enter a 
disabled state, where it does not transmit, receive or repeat, but still responds to GPIO 
controls such as channel steering, alarms and diagnostics. 

• Mixed Alarms - This alarm type could be major or minor, depending on the availability 
of a backup repeater and the type of the system configuration. 

The list of major, minor and mixed alarms varies for different repeaters and repeater models. Refer 
to the RDAC application Online Help for further details. 

2.8.1 Connecting Remotely via the Network 

Connecting RDAC via the network allows access to all repeaters in an IP Site Connect or a 
Capacity Plus system. If a system has more than one wide area system (i.e. more than one Master 
repeater) then the RDAC application is required to know the static IP address and UDP port of 
each of the Master repeater. A single RDAC application supports up to eight IP Site Connect or 
Capacity Plus systems (i.e. eight Master repeaters). It will learn the addresses of the other 
repeaters through communication with each Master. Similar to repeater communication, the RDAC 
application should not require any specific firewall configuration. It will require the appropriate 
authentication be entered that is being utilized by the repeaters in the IP Site Connect system or 
Capacity Plus system. When connecting to multiple IP Site Connect or Capacity Plus systems, 
RDAC must be configured with a different UDP port for each Master. 

Although the network connection is designed for “connecting remotely”, a local network connection 
in close proximity to the repeater is supported. 

The RDAC-IP application can communicate with enabled and disabled repeaters, knockdowned 
repeaters, digital and analog repeaters, and wide and local area repeaters. As long as they are on 
the network and communicating with the same Master repeater that the RDAC application is 
communicating with, they will be controllable via the application. 
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It is important to note that over-use (or misuse) of RDAC diagnostics could cause strain to the 
network link and therefore, cause voice degradation. For example, numerous requests for status 
or error logs could cause excess traffic on a network link which could delay voice through the 
network. Please review the network bandwidth considerations in later chapters. 

2.8.2 Connecting Locally via the USB 

Connecting RDAC locally via the USB provides the user with all the services of RDAC but only 
allows access to the local repeater. This connection is very useful if the repeater is in close 
proximity to the dispatch center or while performing service or trouble shooting locally. 
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2.8.3 Connecting Locally via GPIO Lines 

Connecting locally via GPIO lines only allows access to the local repeater. The user has access to 
the repeater control services as well as access to indications that a minor or major alarm has 
occurred from the GPIO lines. The GPIO lines can be configured in various ways and can be 
integrated to communicate with a variety of external equipment. 

A custom cable is needed to connect the repeater accessory port to the outside control device. 
Below is an example of one configuration. Note that the pin out of the cable is dependent on how 
the GPIO lines are provisioned via CPS. 
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2.8.3. 1 RDAC Local Settings Rear Accessory Port 
CPS Programmable Pins 

The rear accessory also has some pins that can be programmed to specific input/output functions. 
These pins can be programmed to either active high or low. See the table below for descriptions of 
these functions available for each GPIO pin. 



CPS Programmable Pins 


Description 


Major Alarm (Locked State) 


This output pin is used to report a major alarm has happened 3 times, been 
reset three times, and the repeater is in now locked state. 


Minor Alarm 


This output pin is used to report minor alarm(s) is happening on the 
repeater. 


Repeater Disable 


Asserting this input pin triggers the repeater to enter disabled state. In this 
state, the repeater can not execute repeat functions. 

Releasing this input pin will revert the repeater back to enabled state where 
the repeaters can start repeating calls. 


Tx Power Level High 


Asserting this input pin triggers the repeater to change the TX power level 
to be high. 

Releasing this input pin will revert the repeater back to TX low level low. 


Repeater Knockdown 


Asserting this input pin triggers the repeater to temporarily enter Repeat 
Path Disable Mode. In this mode, the repeater’s transmitter will only be 
enabled by the external PTT and the audio source will be the Tx Audio 
Input pin. 

Releasing this input pin will revert the repeater back to Normal Mode where 
the repeaters transmitter can be activated by a qualified RF signal on the 
receive frequency. 

*Note that repeater knockdown is not supported in digital mode. 

*ln Dynamic Mixed Mode system, this feature is not supported during an 
ongoing digital transmission. 


Channel Change 


There are up to 4 pins that can be configured and used for channel change. 
The repeater can support up to 16 channels. 

Asserting this input pin represents 1 . 

Releasing this input pin represents 0. 

0000 represents first channel, 1111 represent the last channel. 
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2.8.4 Redundant Repeater Setup 

By using the alarm feature and control feature together, it is possible to setup redundant repeaters. 
So that when one repeater fails, the standby repeater can take over the repeat function. 

Before installation, both repeaters are programmed with the same channel information. The 
installer configures one repeater as primary repeater and the other one as standby repeater. For 
the primary repeater, the installer configures one GPIO pin for major alarm reporting and 
configures the pin’s polarity. Additionally, it configures via CPS in the primary repeater to indicate 
the availability of a standby repeater. For the standby repeater, the installer configures one of its 
GPIO pins as repeater disabled control input pin and its polarity opposite of the primary repeater’s 
alarm pin polarity. When the primary repeater’s alarm pin becomes active it deactivates the 
disabled pin and the standby repeater becomes enabled. The antenna system is connected to the 
primary repeater and also connected to an antenna switch. The antenna switch is external to the 
repeater hardware. The installer connects the primary repeater’s alarm pin (output pin) and 
standby repeater’s repeater disable pin (input pin) and the antenna switch all together. The 
installer powers on the primary repeater first and verifies it is working with no major alarm reported. 
Then the installer powers on the standby repeater. 




Primary Repeater Standby Repeater 



When a major alarm happens three times in the primary repeater and the repeater enters the 
locked state, the primary repeater will set the major alarm GPIO pin to active level. The standby 
repeater detects the disable pin is changed to inactive level and it becomes enabled. The antenna 
switch is also triggered which changes the antenna to the now active repeater. 

Once the fault in the primary repeater is addressed, the repeater is removed from the locked state 
and reset, the primary repeater will enabled and again become the primary repeater. The standby 
repeater will become disabled. 
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If repeaters are operating in IP site Connect or Capacity Plus mode, they must both have existing 
IP network connections and be communicating with the Master. Since they are both on the 
network, they must have different IP Addresses. Although the system will not send voice to a 
disabled repeater, it will require link management. In IP Site Connect, ensure taking this into 
consideration when planning for network bandwidth, See “Required Bandwidth Calculations” on 
page 312 for details on calculating the bandwidth for IP Site Connect. 

NOTE: A redundant repeater connected to the IP Site Connect system or Capacity Plus system 
counts in the total number of supported peers. 

It is also important to note that when setting up the Master repeater of an IP Site Connect or 
Capacity Plus system into a redundant configuration, the network link must also be switched with 
external hardware similar to that of an RF Antenna. In this case, the IP Address of both the 
Primary and the Standby repeaters must be the same since all the Peers communicate with it 
using this IP address. As they have the same IP Address, they cannot be connected to the 
network at the same time. This also means that the standby repeater cannot be contacted via a 
network RDAC application while not in the primary repeater role since it is not connected to the 
network. Because the two devices have the same IP address but different MAC addresses, Peers 
may not be able to contact the Master repeater until the router and repeater ARP tables are 
updated. Depending on router configuration this could take up to 15 to 20 minutes. It is 
recommended to consult the Network Administrator for details on setting the ARP interval within 
the customer’s network. 

2.8.5 Dual Control Considerations 



It is possible to have RDAC connected locally, over the network, and connected via GPIO lines 
simultaneously to a single repeater. In this case, the repeater can be controlled through GPIO as 
well as through the network. The user should be aware that it is not recommend using both 
methods to control the repeater at the same time. Note that after a control command has being 
executed from RDAC application, the control console connected via GPIO may no longer indicate 
the state of the repeater correctly since it will be reading the state of the hardware pin rather than 
the internal repeater state. In other words if the external application has pulled a pin low or high, 
the repeater cannot change the level of that pin after RDAC has made a change. 

2.8.6 Digital Voting Control and Monitor 

RDAC can be used to control digital voting such as enabling or disabling the feature, force vote, 
and display voting status. See “Digital Voting” on page 339 for more details. 
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2.8.7 General Considerations When Utilizing the RDAC Application 
to Set Up the Network Connection 

When utilizing the RDAC application to communicate with multiple IP Site Connect or Capacity 
Plus systems, each system’s network topology has to be considered independently. This is 
important because some connections may utilize a LAN configuration (See “Local Area Network 
(LAN) Configuration” on page 254), while others utilize a WAN configuration (See “Wide Area 
Network Configuration” on page 255). The main difference being that local area configurations 
utilize the master repeater’s local IP address, while wide area configurations utilize the wide area 
IP address. 

Connecting a single RDAC application to numerous systems that were previously residing on the 
same LAN, VPN, or WAN requires minimal configuration change. The RDAC application needs to 
be configured with each master repeater’s IP address and a unique UDP port for each system. 
This is because the IP address of the master repeater that can be reached at wide or local area IP 
address, does not change. 

When connecting a single RDAC application to systems that were previously residing on 
independent LANs or VPNs, the following configuration options can be considered: 

1. Combine both networks into one LAN or VPN, which most likely requires changing 
repeater IP addresses in one of the networks. 

2. Connect to each LAN through a WAN. As it is now a wide area configuration, this requires 
some changes because all peers (including the RDAC application) are now required to 
utilize the master repeater’s wide area IP address, instead of the local IP address. 

3. Place the RDAC on the LAN of one of the sites. This requires one system to communicate 
using the local IP addresses, while the others, the wide area IP address. 

In all of the options mentioned above, each system must utilize a unique UDP port configured via 
the RDAC application. 

An IP Site Connect system supports analog, and digital conventional channels. A Capacity Plus 
system supports only Capacity Plus channels. A Linked Capacity Plus system supports only LCP 
channels. 

If a channel is changed to a channel not supported by the system, the channel’s repeater does not 
reconnect to the system, and the repeater will not be visible in RDAC. Therefore, it is strongly not 
recommended to change a channel’s mode to an unsupported mode of the system. 
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2.9 Repeater Diagnostics System Enhancement 

Repeater Diagnostics, Alarm and Control(RDAC) described in section 2.8 is for monitoring of 
hardware alarms, diagnosis of RSSI, power level, repeater state, and repeater control of enable/ 
disable, channel change and so on. In contrast, Repeater Diagnostics System (RDS) feature 
focuses more on software alarm detection which provides more troubleshooting capability in the 
field. The RDS feature uses RDAC to control and retrieve the diagnostic information from the 
repeaters. 

The following services are provided: 

• Enable and disable RDS 

• Repeater software alarm control 

• Configure automatic polling interval 

• Detect and report software alarms 

• Retrieve and clear software alarms 

• Log file management 

Software alarms detected in RDS are categorized below: 

• OTA layer: FCC interference type I and II; Color code failure; MFID failure and etc. 

• IP layer: Link status between repeaters; Call streaming failure; 

• Network layer: Network cable error; Gateway error; DHCP error and etc.; 

All the services in the list above are available in both analog and digital mode. The connection 
between repeater and RDAC application can be network via IP or locally via USB. 

When working over the IP network, the application communicates with all repeaters within the 
system; when working locally, the RDAC application connects to a single repeater via USB. All 
services in the list above are available through the RDAC application. 

The alarm information of multiple repeaters in the same system will be stored in the same log file 
by RDAC application. PC timestamp and repeater peer ID are added to each alarms in the log file. 
Different log folders are used for different system configurations. 

RDS feature will be applied in MOTOTRBO 32 MB Repeaters. 
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2.10 IP Repeater Programming (IRP) 

IP Repeater Programming allows a system administrator to provision and to upgrade repeaters 
within the system utilizing the IP network. This feature is supported on repeaters equipped with a 
32 MB memory running on firmware version R01 .07.00 or later. Additionally, the Master repeater of 
a system configuration must be running on the same firmware version as well. The following 
services are provided: 

1. Repeater Configuration 

• Read the current repeater configuration 

• Write a modified repeater configuration 

2. Repeater Upgrade 

• Upgrade repeater firmware and/or codeplug version 

3. Repeater Feature Enable 

• Activate a purchased feature on the repeater 

2.10.1 System Configuration for IRP Support 

Connecting the Customer Programming Software (CPS) to an IP network allows the CPS to 
access all repeaters in an IP Site Connect system and a Capacity Plus system, utilizing their 
backend network connections. The CPS can also leverage IP-based access to Dynamic Mixed 
Mode (DMM) or Single Site repeaters by connecting the repeaters to an IP network and 
configuring each one to act as a single site Master. 

Prior to using IRP, the feature must be configured with the repeater locally connected via USB to 
the CPS application. The CPS can communicate with repeaters of multiple modes; enabled, 
disabled, knockdown, digital and analog. The primary requirement is that the repeater must be on 
an IP network and communicating with a Master repeater or acting as one. However, the CPS can 
only connect to one Master at a time and can only program a single repeater at a time. 

Once the repeater has been properly configured and installed in a networked configuration, the 
CPS needs to be directed to the IP address of a Master repeater as defined by the repeater 
configuration. If a system has more than one wide area system (i.e. more than one Master 
repeater), then the CPS is required to know the static IP address and UDP port of each of the 
Master repeater. The CPS then learns the addresses of other repeaters connected to the Master 
once the application connects to the Master. 

Unlike repeater-to-repeater communication, the CPS application may require firewall 
configuration. This is to allow the repeater to make a secure connection to the CPS application on 
the PC. If the PC resides behind a firewall, the firewall will need to be configured to allow inbound 
traffic (repeater-to-CPS) on a specific CPS TCP port that is configurable in the application. Upon 
initiating an IRP action, the CPS communicates its opened TCP port number to which the repeater 
attempts to connect. If multiple CPS applications (different PCs) are behind a single firewall, each 
application must use a unique TCP port number, and the firewall must be configured to correctly 
route TCP traffic to the corresponding application. 

To authorize access to the repeater, codeplug password authentication on a per repeater basis, is 
optional and configurable via CPS. The codeplug password can be provisioned in the repeater 
prior to using this feature. 
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NOTE: Using the CPS to provision or upgrade a repeater will temporarily disable the repeater 
until the operation is completed. The duration of the disabled repeater depends on the 
network bandwidth and amount of data that is transferred to complete a selected 
operation. 
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2.11 Over The Air Battery Management 

When a battery fails and communication is lost, it impacts every aspect of an organization from 
serving customers to saving lives. But monitoring and maintaining the status of a large fleet of 
batteries can be time-consuming, inefficient and potentially overwhelming. 

That is why the proprietary IMPRES™ Battery Fleet Management technology was created. It 
saves the guesswork, complexity and costs of managing hundreds even thousands of radio 
batteries and chargers wherever they’re located, and makes it easier for users to do their work 
safely and successfully. 

IMPRES Battery Fleet Management already supports collection of battery information each time 
an IMPRES battery is inserted into an IMPRES charger. And now IMPRES Battery Fleet 
Management supports automatic collection of battery information over the air while the radios are 
in use. This removes the need for wired network connections, Charger Interface Units, and remote 
clients at charger locations. 

With IMPRES Battery Fleet Management, existing or customizable reports can be utilized to see 
the most relevant information. Data is stored in a database and can be exported to an Excel file or 
printed. IMPRES Battery Fleet Management software records and organizes a variety of data so 
the user can: 

• Evaluate whether batteries are meeting their performance criteria 

• Determine when batteries are nearing their end-of-life 

• Eliminate unexpected downtime and work interruptions 

• Avoid the expense of throwing batteries away prematurely 

• Identify batteries that are missing, misplaced or inactive 

• Identify radios that are not using IMPRES batteries 

• Decide exactly when to buy new batteries 

• Optimize charger utilization 

NOTE: Over the air battery management focuses on managing the long term health of the 
batteries. It is not meant to acquire the current real-time energy levels of all radios within 
the system. 

Automatic collection of battery information over the air is supported in the following system 
architectures: 

• Direct Mode (including Dual Capacity) 

• Single Site Repeater 

• IP Site Connect 

• Capacity Plus 

• Linked Capacity Plus 

Collection of battery information over the air is supported in the following radios when they are 
utilizing IMPRES batteries: 



XPR7580, XPR7550, XPR7380, XPR7350, XPR3500, XPR3300 Series 
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2.11.1 How Does It Work? 



The Battery Fleet Management application (BMA) communicates with the radio system through an 
IP data gateway. The IP data gateway can be either the Motorola Network Interface Service 
(MNIS), which communicates via IP to the repeaters in the system, or a mobile radio configured as 
a control station. 




Figure 2-20 Battery Fleet Management Application (BMA) set up 

The Battery Fleet Management application (BMA) starts empty. Within a few hours after a radio 
powers up, it registers its current battery over the air with the BMA. If the battery has never been 
registered with the BMA before, the BMA creates a new record for the battery and reads its battery 
data over the air. If the battery has been registered with the BMA before, the BMA checks the last 
time the battery’s data was read. If it has not been recently read, the BMA reads the battery data 
over the air. If it has been recently read, no action is taken. Radios register their battery about once 
a day, and a battery’s data is read once every few weeks. 

2.11.2 How To Configure Automatic Over The Air Battery Data 
Collection 



The radios must be programmed with the radio address of the IP data gateway the Battery Fleet 
Management application is utilizing, and over the air battery management must be enabled on the 
channel the IP data gateway is monitoring. 

The Battery Management Server ID can be found in the network section of the radio CPS, under 
Services. Digital capable channels have a checkbox to enable Over-the-Air Battery Management. 
The radio only sends automatic battery registrations on channels that are enabled for over the air 
battery management. 

Per standard data system configuration, the IP data gateway, either MNIS or a control station, 
must have a unique radio ID on the system. The IP data gateway utilized by the BMA must be 
configured for confirmed data calls, otherwise the success rate of the over the air battery 
management messaging will be noticeable low. 

If there is a UDP port conflict on the PC, the IP data gateway, either MNIS or a control station, and 
the Battery Management Application can be configured with a different UDP Port. The setting can 
be found in the Network section of CPS for the control station, and the Configuration menu of the 
Battery Management Application. 
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Over the air battery management messaging does not revert, therefore the BMA’s IP data 
gateways need not be monitoring revert channels. 

Since the over the air messaging utilizes the MOTOTRBO IP data service, all pre-requisites and 
limitations of the standard IP data service apply to battery management. 

2.11.3 System Level Optimizations 

There are two timers that may require adjustments for optimal performance: the Battery Data 
Refresh Timer, and the Radio Hold Off Timer. The default values should be acceptable for most 
scenarios. 

2.1 1 .3. 1 Battery Data Refresh Timer 

The Battery Data Refresh Timer controls how frequently the battery data is read. Its default value 
is 21 days (i.e. 3 weeks). Battery data changes fairly slowly, therefore it unnecessary to read it 
over the air very often. The more often the battery data is read, the larger the load on the system. 
This is especially true if the system contains a very large number of radios. The Battery Data 
Refresh Timer can be found in the Preferences of the Battery Fleet Management application. 

2.11.3.2 Radio Hold Off Timer 

The Radio Hold Off Timer controls how long after power up does the radio wait before registering 
its current battery with the Battery Fleet Management application. Its default value is 2 hour. The 
radio waits for a random time between 30 minutes and the configured Radio Hold Off Timer. 

If a system contains a very large number of radios, the Radio Hold Off Timer should be increased 
to minimize the over the air message collisions and congestion during shift changes or other 
scenarios where many radios power cycle within a short period of time. Because battery data is 
normally only read once every three weeks, delaying a battery registration a few hours after power 
up does not impact the long term automatic battery data collection process. 

The Radio Hold Off Timer can be found in the Preferences of the Battery Fleet Management 
application. It can also be configured per radio within the Radio Information dialog. The Battery 
Fleet Management application informs the radio of the new Radio Hold Off Timer the next time it 
registers. The radio utilizes the new Radio Hold Off Timer starting after the next power cycle, which 
usually occurs the next day. 

After CPS configuration, the radio registers within minutes after power up prior to its first 
successful registration with the Battery Fleet Management application. 

2.11.3.3 Performing A Manual Battery Data Read 

The automatic over the air battery data collection process should keep the battery data in the 
Battery Fleet Management application (BMA) up to date, within the duration Battery Data Refresh 
Timer. 

If immediate battery data refresh is needed, the Battery Fleet Management application (BMA) 
allows the user to request a manual read of a radio and battery. 
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If the requested radio is not available (turned off, out of range, busy in a call, in a charger, etc.), the 
BMA marks the radio and battery to be read the next time either registers with the BMA. If the 
requested radio is available, but the attached battery does not match the requested battery, the 
BMA reads the attached battery and then marks the requested battery to be read the next time it is 
registered with the BMA. 

NOTE: It is not recommended to perform rapid manual requests. The resulting data transfers may 
cause disruption to other services. 

2.11 .3.4 A Radio Utilizing A Battery In A Charger 

When a radio is placed in a charger while powered on, its battery data cannot be collected over the 
air. The radio does not register an IMPRES battery while in the charger. The automatic collection 
process pauses, and then continues when removed from the charger. A radio does not respond to 
a manual battery data read request over the air while in a charger. 

It is expected that a radio spends at least the duration of the Radio Hold Off Timer powered up and 
not in a charger per day. If a radio is always in a charger, a wired solution utilizing Charger 
Interface Unit is the best solution. 

If a radio is powered up (i.e. turned on) while already in the charger, it will not recognize the 
IMPRES battery and registers as a non-IMPRES battery with the Battery Fleet Management 
application. When the radio is removed from the charger the first time after power up, the radio 
registers its battery as an IMPRES within the duration of the Radio Hold Off Timer. 

2.11.4 Advanced System Deployments 

There are generally two types of over the air battery management deployments for the IMPRES 
Battery Fleet Management application (BMA), those that connect to the radio system through an 
IP link via the Motorola Network Interface Service (MNIS), and those that connect to the radio 
system through the over the air link via control stations. It’s important to note that the BMA sends 
IP data messages targeted towards the radios and is agnostic to the underlying radio system 
architecture. 

2.11.4.1 MOTOTRBO Network Interface Service (MNIS) Deployments 

The following parameters within the MNIS software must be set: 

• Confirmed Layer 2 Data Enabled 

• A radio ID that matches the Battery Management Server ID configured in the fielded 
radios. 

The Battery Fleet Management Application itself does not require presence via the Device 
Discovery and Mobility Service (DDMS), but the MNIS does require DDMS in order to route the 
data to the appropriate channel and site. The Battery Fleet Management Application and MNIS 
must reside on the same PC. Radios in the field always send over the air battery management 
messages confirmed regardless of the radio’s configuration. 
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2.11.4.1.1 Single Site 

Over the air battery management is supported through MNIS to single site repeaters. MNIS can 
connect to 8 single site repeaters at a time. In order for MNIS to perform mobility, DDMS must be 
installed, and ARS must be enabled in the radios. 
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Figure 2-21 BMA Deployment in Single Site with MNIS 

2.11.4.1.2 IP Site Connect 

Over the air battery management is supported through MNIS to IP Site Connect systems. MNIS 
can connect to 8 IPSC systems at a time. Each system can have 15 sites. 8 systems can have 16 
wide area channels. If utilizing local channels, one MNIS supports 32 wide and local channels 
overall. In order for MNIS to perform routing, DDMS must be installed, and ARS must be enabled 
in the radios. 
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Figure 2-22 BMA Deployment in IP Site Connect with MNIS 

2.11.4.1.3 Capacity Plus 

Over the air battery management is supported through MNIS to a Capacity Plus system. MNIS 
can connect to one Capacity Plus system. In order for MNIS to perform routing, DDMS must be 
installed, and ARS must be enabled in the radios. 
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Figure 2-23 BMA Deployment in Capacity Plus with MNIS 

2.11.4.1.4 Linked Capacity Plus 

Over the air battery management is supported through MNIS to a Linked Capacity Plus system. 
MNIS can connect to one Linked Capacity Plus system. In order for MNIS to perform routing, 
DDMS must be installed, and ARS must be enabled in the radios. 



126 



System Feature Overview 



Battery 

Managetneffl 



DDMS 



IP 



Network 

Interface 

Service 

(MNIS) 



PC 




IP 



IP Network 





Figure 2-24 BMA Deployment in Linked Capacity Plus with MNIS 

2.11.4.2 Control Station Configurations 

The following parameters within the control stations must be set: 

• Confirmed Layer 2 Data Enabled 

• A radio ID that matches the Battery Management Server ID configured in the fielded 
radios. 

The Battery Fleet Management application itself does not require presence via the Device 
Discovery and Mobility Service (DDMS), but the MCDD does require DDMS in order to route the 
data to the appropriate control station, and therefore the appropriate channel. The Battery Fleet 
Management Application, MCDD and DDMS must reside on the same PC. 

If MCDD is not utilized, a static IP route may need to be manually entered in the PC that routes all 
radio data through the control station’s network interface. Radios in the field always send over the 
air battery management message confirmed regardless of the radio’s configuration. 

2.11.4.2.1 Direct Mode 

Over the air battery management is supported through a control station in direct mode (including 
dual capacity). The USB Driver is required in all control station configurations in order for the 
Battery Fleet Management Application to send IP data grams through the control station. 
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Figure 2-25 BMA Deployment in Single Channel Direct Mode with Control Stations 

Over the air battery management is supported through up to 16 control stations in direct mode 
(including dual capacity). When using multiple control stations, the Multi-Channel Device Driver 
(MCDD) and the Device Discovery and Mobility Service (DDMS) are required. ARS must be 
enabled in the radios. 
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Figure 2-26 BMA Deployment in Multi-Channel Direct Mode with Control Stations 

2.11.4.2.2 Single Site 

Over the air battery management is supported through up to 16 control stations in single site 
repeater mode. When using multiple control stations, the Multi-Channel Device Driver (MCDD) 
and the Device Discovery and Mobility Service (DDMS) are required. ARS must be enabled in the 
radios. 
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Figure 2-27 BMA Deployment in Single Site with Control Stations 
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2.11.4.2.3 IP Site Connect 

Over the air battery management is supported through up to 16 control stations in IP Site Connect 
mode. When using multiple control stations, the Multi-Channel Device Driver (MCDD) and the 
Device Discovery and Mobility Service (DDMS) are required. ARS must be enabled in the radios. 
Local channels may require an additional proxy and control stations in order to communicate over 
the air to the local channel. 





Figure 2-28 BMA Deployment in IP Site Connect with Control Stations 

2.11.4.2.4 Capacity Plus 

Over the air battery management is supported through control stations in Capacity Plus mode. 
Only one trunking control station is required. The Multi-Channel Device Driver (MCDD) and the 
Device Discovery and Mobility Service (DDMS) are not required in Capacity Plus. Over the air 
battery management messages are sent on the trunking channels. They are not sent on data 
revert channels. 
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Figure 2-29 BMA Deployment in Capacity Plus with a Control Station 
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2.11.4.2.5 Linked Capacity Plus 

Over the air battery management is supported through control stations in Linked Capacity Plus 
mode. Only one trunking control station is required. The Multi-Channel Device Driver (MCDD) and 
the Device Discovery and Mobility Service (DDMS) are not required in Linked Capacity Plus. 
Over the air battery management messages are sent on the trunking channels. They are not sent 
on data revert channels. 




IP 





Figure 2-30 BMA Deployment in Linked Capacity Plus with a Control Station 

2.11.4.3 Battery Management Application Deployments 

As shown in the previous section, the Battery Fleet Management application sends IP data 
messages targeted towards the radios and is agnostic to the underlying radio system architecture 
or the type of data gateway utilized, MNIS or Control Stations. For simplicity sake, in this section 
only discusses the ‘data gateway’ which represents the DDMS and MNIS, or the DDMS, MCDD, 
USB Driver, and Control Stations. The radio system can be any of the architectures previously 
discussed. 




Figure 2-31 Simplified BMA Deployment Diagram 
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2.11 .4.3.1 Battery Fleet Management Client, Server and Proxy 

The Battery Fleet Management Application is made up from a Client, a Server and a Proxy. 




Figure 2-32 BMA Deployment with Client, Server and Proxy on the same PC 

The Battery Fleet Management Client is the main user interface for the application. The Battery 
Fleet Management Server is where all the battery data is stored. The Battery Fleet Management 
Proxy communicates with the radio system. The Battery Fleet Management Proxy resides on the 
same PC as the Data Gateway (MNIS or control stations). The other components may reside on 
other PCs, as long as there is a direct IP connection between all components. 

2.11.4.3.2 Remote Battery Management Client 

The Battery Fleet Management Application Client can be remotely located away from the Battery 
Fleet Management Server and Proxy. This is useful when the dealer site is not co-located with the 
customer’s site. 




Figure 2-33 BMA Deployment with Client Remote from Server and Proxy 

This is also useful when one battery management user needs to manage multiple systems that 
cannot be accessed with one data gateway. For example, if using control stations to monitor 
systems that are not within RF coverage of each other, multiple sets of control stations and proxies 
must be utilized. Since an MNIS has limitations on how many systems it can connect to, multiple 
sets of MNIS and proxies must be utilized. 
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In the case of remote client, each data gateway has its own Battery Fleet Management Proxy and 
Server. This means that each system’s batteries have their own database and the database is 
often located at the customer’s site. 




Figure 2-34 BMA Deployment with Client Remote from Multiple Server and Proxies 

2.11.4.3.3 Remote Battery Management Proxy 

A remote battery management proxy is similar to the remote client use cases explained earlier, but 
this allows the battery management user to maintain one server for all of their batteries and 
systems. Rather than the servers being located at the customer sites, only the proxy is located at 
the customer sites. This is convenient for the battery management user, but requires the 
connection between the server site and the proxy site to be available all the time since there is 
communication between those components occurring all the time. In contrast, the client only 
communicates to the server when the user is present and reviewing battery data. 

The Battery Fleet Management application handles the mobility between the server and the 
proxies. When a radio registers its battery, the proxy from which it registered is saved in the 
Battery Fleet Management Server in order to route outbound messages. There is only one MNIS 
or one MCDD on one PC at a time. 
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Figure 2-35 BMA Deployment with Multiple Proxies Remote from Server 

2.11 .4.4 Coexistence with Other Data Applications 

The Battery Fleet Management application is supported in system configurations with the Radio 
Management application. Battery Fleet Management and Radio Management may be installed on 
the same computer. 

The Battery Fleet Management application is supported in system configurations with 3rd party 
applications, but there may be some special considerations and configurations required. 

In general, it is recommended that the Battery Fleet Management application be installed on a 
different computer than any other 3 rd party application. There may be various conflicts present, 
message routing being the most common, which may cause issues. Interoperability testing with 

every 3 rd party application in the market is not possible; therefore we only support installations on 
different computers. If installation on the same computer as a 3 rd party application is a must, it is 
recommended you pre-test all functionality before deployment. 

3 rd party applications have a wide array of methods to implement presence notification. In some 
cases, their implementations conflict with our implementation. As described in earlier sections, 
although the Battery Fleet Management application itself does not require presence, some system 
architectures may require it for data routing. 

Radios can be configured to send automatic registration service (ARS) messages through the 
system to the Device Discovery and Mobility Service (DDMS). These messages are utilized by the 
system for presence and mobility. The radios are configured to send these messages to one 
target. If the radios are already configured to send these messages to a third party application’s 
presence service, steps must be taken so that the DDMS can also receive them. 

If installing the Battery Fleet Management application on a system with a 3rd party application that 
utilizes a non-ARS based method of implementing presence, then the Device Discovery and 
Mobility Service (DDMS) can be installed and utilize the automatic registration service (ARS) over 
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the air without any further issues. An example of a non-ARS based method would be monitoring 
for traffic of any kind instead of utilizing the actual presence notification service over the air. This 
allows the radios to send their presence to Motorola’s DDMS. 

If installing the Battery Fleet Management application on a system with a 3rd party application that 
utilizes a Non-Motorola based presence service, then the Device Discovery and Mobility Service 
(DDMS) and Data Gateways must be installed on the system in a passive presence configuration. 

Simply stated, a passive presence configuration means the DDMS and Data Gateways (MNIS or 
Control Stations) are configured to not acknowledge incoming ARS messages, i.e. they act 
passively to incoming messages. This allows the reception of messages by both the 3rd party 
applications and Motorola applications without creating duplicate acknowledgements that might 
collide or conflict in the system. 

2.11.5 Battery Fleet Management Computer Specifications 

2.11.5.1 Operating System Requirements 

• Windows 7 x86 and x64 

• Windows 8 x86 and x64 

• Windows Server 2003 x86 and x64 

• Windows Server 2008 x86 and x64 

• Windows Server 2008 R2 x64 

2.11.5.2 Hardware Minimum Requirements 

The IMPRES Battery Fleet Management application can either be installed on a client/proxy 
computer or a server computer. Although the installation package is the same for client and server 
computers, the hardware installation requirements are different for each. 

2.11.5.3 Server Hardware Minimum Requirements 

• DVD drive 

• 1 GB of hard disk space 

• 2 GB RAM 

2.11.5.4 Client/Proxy Hardware Minimum Requirements 

• 1 USB (Universal Serial Bus) Port 

• DVD drive 

• 200 MB of hard disk space 

• 1 GB RAM 
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2.12 Over-the-Air Radio Programming (OTAP) 

When the need to program a radio or a fleet of radios occurs, the process can take place at the 
customer location or the dealer’s shop. However, the process of programming radio parameters, 
features, contact lists, and others can be troublesome. 

Some issues encountered include - difficulty to locate all radios, delays waiting for radios to be 
brought in for programming, radios mounted in vehicles, operation and downtime during 
programming, wasted time traveling to/from customer location, only a limited number of radios can 
be programmed simultaneously, and so on. It is often difficult for dealers to extract value for this. 
Therefore, radio programming is viewed as a hassle, time consuming, and inefficient. 

To support this need, the MOTOTRBO Radio Management (RM) now offers the following services 
with software version R02. 10.00 or later: 

• Writes and reads radio configurations over-the-air 

• Manages up to 5000 radio configurations 

• Group and individual archive management 

• Application and radio mutual authentication 

• Synchronized configuration switchover 

• Radio user receives one time option to accept or delay 

• Scheduling of over-the-air operations 

• Unmanned batch processing of numerous over-the-air operations 

• Remote client capability 

• Multi-customer and system capable 

• Optimized performance using Presence Services 

• Compressed and differential configuration transfer 

• Designed to allow voice traffic priority while transferring 

• Utilizes existing over-the-air encryption 

• Session logging 

• Historical reporting 

The above features are available in all digital architectures including: 

• Direct Mode (12. 5e and 6. 25e) 

• Single Site Repeater 

• IP Site Connect 

• Capacity Plus 

• Linked Capacity Plus 

The services that are supported are not available to the ADP developers. 

The following features and services are specifically not supported by OTAP: 

• radio software upgrades 

• language packet updates 

• radio tuning parameter updates 

• device recovery 
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• update or download voice announcement files 

• radios prior to software version R02.1 0.00 

• over-the-air repeater programming (only IP Repeater Programming is available) 

• programming while in Connect Plus or Passport Mode 

• programming while in Analog Mode 

2.12.1 Basic Deployments of OTAP Software 

There are six basic deployments of Radio Management (RM) for OTAP. These are used as the 
building blocks for more complicated configurations. The configurations are: 

• Local Single Channel Configuration 

• Local Single Channel Configuration with Presence 

• Remote Client Configuration 

• Remote Client Configuration with Multiple RM Servers 

• Remote Device Programmer Configuration 

• Multi-Channel Configuration 

2.12.1.1 Local Single Channel Configuration 

The RM application utilizes the existing MOTOTRBO IP data service to communicate with the field 
radios over-the-air. Connectivity with the system can be achieved over-the-air through control 
stations or over the IP network utilizing the MOTOTRBO Network Interface Service (MNIS). No 
other over-the-air data application is supported on the same PC as the RM. 

This control station setup requires a radio to be configured as a control station, connected to the 
RM PC via a USB cable and utilized as the data gateway into the radio system. The standard radio 
USB driver is also required. 




Figure 2-36 Single Channel Non-Remote RM Configuration Through Control Station 



The MNIS setup requires the MNIS software to be installed on the RM PC and the Network 
Application Interface be enabled in the repeaters. MNIS deployments are not available in Direct 
Mode since the MNIS interfaces directly with the repeaters, and there are no repeaters used in 
Direct Mode. 
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Figure 2-37 Single Channel Non-Remote RM Application Configuration Through MNIS 



2.12.1.2 Local Single Channel Configuration with Presence 



The RM can utilize the ARS and the presence service of the DDMS software to optimize over-the- 
air operations. When utilized, radios are only contacted if they are present. The ARS must be 
configured in the radios. 

Without presence and the DDMS, the RM attempts to contact each radio one by one, regardless if 
they are present on the system or not. For optimal performance, it is recommended that the 
presence service be utilized. 

If utilized, the DDMS is installed on the same computer as the control stations or the MNIS. 




PC 

Figure 2-38 Single Channel Non-Remote RM Application with Presence and Control Station 
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PC 



Figure 2-39 Single Channel Non-Remote RM Application with Presence and MNIS 
The RM consists of three major components: 

• RM Client: Main User Interface 

• RM Server: Storage of Configurations 

• RM Device Programmer: Communication to Radio System 
NOTE: The “RM Device Programmer” is also known as the “RM Proxy”. 

In local deployments, all three components can be installed at the same time on the same 
computer. This is most useful when the system administrator is within RF coverage of the radio 
system. Below is a diagram showing the individual components. This is the same when utilizing 
the MNIS. 




Figure 2-40 Single Channel Non-Remote RM Application with Presence (RM Client, RM Server, and RM 

Device Programmer Shown) 
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2.12.1.3 Remote Client Configuration 

If the system administrator is not within RF coverage of the system, it is possible for the RM Client 
to be installed on a different PC and remotely access the RM Server and Device Programmer over 
an IP network. Direct network connectivity is required between the RM Client and the RM Server, 
therefore a VPN must be used or they must reside on a private network. The RM Server, RM 
Device Programmer, and control stations are located on the same PC. 




Figure 2-41 Remote RM Client from RM Server with Control Station 



When utilizing the MNIS, the RM Client can also be installed on a different PC from the RM Server. 
This allows the RM Server and RM Device Programmer to remain centrally located while the RM 
Client is located at another location on the IP network. The RM Device Programmer must be 
installed on the same PC as the MNIS. 




Figure 2-42 Remote RM Client from RM Server with MNIS 



2.12.1.4 Remote Client Configuration with Multiple RM Servers 



The RM Client can connect to any RM Server, but only one at a time. This allows the system 
administrator access to different customers with non-overlapping RF coverage from one location. 
Although the RM Server, Device Programmer, and control stations must be within RF coverage, 
the RM Client does not. Each RM Server manages its own set of radios. Direct network 
connectivity is required between the RM Client and the RM Server; hence a VPN must be used or 
they must reside on a private network. However, it is not necessary for the network connection 
between the RM Client and the RM Server to be up all the time. The system administrator can set 
up a job with one RM Server, and then disconnect. The RM Server continues to execute. 
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Figure 2-43 Remote RM Client with Multiple RM Servers with Control Station 



Although one MNIS can connect to multiple remote IPSC and single site systems over an IP 
network, it can only connect to one Capacity Plus or LCP system at a time. Therefore, multiple 
MNISs should be deployed. A remote RM Server, Device Programmer and MNIS can be located at 
each Capacity Plus system, or at one of the sites of an LCP system. They can be centrally 
accessed with a RM Client. 
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Figure 2-44 Remote RM Client with Multiple RM Servers with MNIS 
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2.12.1.5 Remote Device Programmer Configuration 

The RM Server can support up to 128 RM Device Programmers. This allows the system 
administrator to have all radios in one RM Server and have access to different sites with non- 
overlapping RF coverage. The Device Programmer and control stations must be within RF 
coverage of their corresponding systems, which is unnecessary for the RM Server. 

NOTE: If necessary, the RM Client can be remote from the RM Server as well. 

Stable, direct network connectivity is required between the RM Server and RM Device 
Programmers. Therefore a VPN must be used, or they must reside on a private network. If a 
stable, direct network connectivity is not possible, a Remote Client Configuration with multiple RM 
Servers installed on the same PC as the Device Programmers, may be required. 




PC 



Figure 2-45 RM Server with Remote Device Programmers and Control Stations 

If utilizing presence, the Device Programmer where the target radio has registered, services jobs 
for that radio. A Device Programmer can also be configured to only service a specified set of 
radios. This is accomplished by setting the radios to a group within the RM Server, and then 
configuring the Device Programmer to service the group. 

Although one MNIS can connect to multiple remote IPSC and single site systems over an IP 
network, it can only connect to one Capacity Plus or LCP system at a time. Therefore, multiple 
MNISs should be deployed. A remote Device Programmer and MNIS can be located at each 
Capacity Plus system, or at one site of an LCP system. They can share one central RM Server 
which can be accessed with a RM Client. 



The RM Device Programmer must be installed on the same PC as the MNIS. 
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Figure 2-46 RM Server with Remote Device Programmers and MNIS 



2.12.1.6 Multi-Channel Configuration 



Multiple conventional channels are supported per RM Device Programmer in both local and 
remote configurations. This requires a control station per channel, up to 16 are allowed. Because 
radios can move from channel to channel, this configuration requires the MCDD and DDMS to be 
installed on the same PC. The MCDD tracks the location of the radios as they move from channel 
to channel. As they register with the DDMS, the MCDD updates the routing accordingly. 




PC 

Figure 2-47 Multi-Channel Non-Remote RM Application Configuration with Control Stations 



It is not recommended to utilize multiple control stations without the MCDD and DDMS. Without 
them, there is no method for RM messages to be properly routed on the appropriate channel. 
Specific routing can be added in the PC, but this means radios can only be contacted on a specific 
channel. Another option is to configure the PC to broadcast on all channels, but this is an extreme 
waste of bandwidth. 

NOTE: A multiple channel configuration can be deployed with remote RM Device Programmers, 
remote RM Servers, or a remote RM client. 
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The RM works the same regardless if the control stations are communicating in direct mode, 
single site repeater mode, dynamic mixed mode, IP Site Connect mode, Capacity Plus mode, or 
Linked Capacity Plus mode. 

When utilizing MNIS with DDMS, there is no need for MCDD. DDMS handles the mobility in single 
site and IPSC systems. DDMS requires ARS to be enabled in the fielded radios. The MNIS can 
connect to eight (8) conventional systems. 




Figure 2-48 Multi-Channel Non-Remote RM Application Configuration with MNIS 



2.12.2 Process Flow for Over-the-Air Programming 



There are five high level steps for OTAP: 

• Initial programming of the essential communication parameters into the radio via wired 
CPS 

• Populating the RM Server with the current radio configurations 

• Modifying the radio configuration within the RM Server 

• Delivering the modified radio configurations to the radios 

• Applying (or switching over) the delivered radio configurations 
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2.12.2.1 Initial Programming of the Essential Communication Parameters 
into the Radio via Wired CPS 

Prior to the first time a radio is programmed over-the-air, it must be provisioned with CPS via a 
wired connection. All the essential communication parameters required for the radio and the RM to 
communicate with each other on the system must be programmed. This includes: 

• Radio software upgrades 

• System and channel parameters 

• Data parameters 

• Radio ID 

• OTAP authentication key 

2.12.2.1.1 Radio Software Upgrades 

Any radio software upgrades required for over-the-air operation must be updated via configuration 
software in a wired operation. Radio software upgrades are not supported over-the-air. 

2.12.2.1.2 System and Channel Parameters 

All system and channel parameters required for the radio to communicate with the system must be 
configured prior to the first operation over-the-air. This includes the standard communication 
parameters such as frequencies, color codes, channels, talkgroups, voice privacy keys, and so on. 
If the radio cannot communicate on the system properly, the RM will not be able to contact it. 

2.12.2.1.3 Data Parameters 

RM utilizes the MOTOTRBO data service to communicate with the radios. This means that all 
communication parameters required for data capability must be provisioned prior to the first 
operation over-the-air. This includes the ARS parameters. 

2.12.2.1.4 Radio ID 

The radio ID must be programmed prior to the first over-the-air operation. There are rules about 
the data service and the uniqueness of the radio’s radio ID that must be followed. 

In conventional configurations, the data service requires every radio on a logical channel to have a 
unique radio ID. If a data application is communicating on multiple channels, and an MCDD and 
DDMS are present, every radio communicating through the DDMS and MCDD must have a unique 
radio ID, even if they are on different logical channels. 

If the RM communicates through a DDMS and a MCDD to multiple channels, every radio across 
those channels must have a unique radio ID. 

If utilizing a centralized RM Server to communicate with multiple systems using Remote Device 
Programmers, every radio across those systems must have unique radio IDs. If this is not 
achievable, then OTAP sessions to systems with duplicate IDs have to be executed sequentially - 
only one at a time, or a separate RM Server must be utilized for each system. Ultimately, end-user 
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fleets should be reconfigured to unique IDs so that multiple OTAP sessions to multiple customer 
fleets can be processed simultaneously. 

In Capacity Plus and Linked Capacity Plus, every radio must have a unique radio ID. If one 
customer contains multiple Capacity Plus systems, then every radio across those systems must 
have unique radio IDs. If this is not achievable, then one customer must have multiple RM 
Servers, one for each Capacity Plus system. This only limits the ability to connect to both systems 
at the same time. 

2.12.2.1.5 Over-the-Air Programming Authentication Key 

The only new OTAP parameter required to be programmed in the radio is the OTAP authentication 
key and key ID. It must be present in both the radio and in the RM prior to the first over-the-air 
operation. The OTAP authentication key can be changed over-the-air if the current key in the radio 
matches the previous key entered in RM. 

2.12.2.2 Populating the RM Server with Current Radio Configurations 

After the radios have been initially programmed with wired CPS, their configurations must be 
populated into the RM Server. There are three different ways to populate the RM Server with the 
current radio configurations: 

• Archive importing 

• Entering radio identity information 

• Radio identity file importing 

2.12.2.2.1 Archive Importing 

Radios can be populated into the RM Server by importing the saved archive as each radio is 
programmed with its initial programming. This requires the CPS to have IP network connectivity to 
the RM Server during the initial programming. 

If IP network connectivity is not available while initially programming the radios, each radio archive 
can be saved and imported into the RM Server when connection is available. One archive must be 
saved and imported for each radio since their specific identity information must be available in 
order to properly identify them in the RM Server. 

The saved archive to be imported should contain the over-the-air authentication key, Enhanced 
Privacy keys, and Symmetric Keys that were entered in CPS prior to programming the radio via 
the wire. These are not available if a radio is only read with wired CPS since these cannot be 
retrieved from a radio. If not within the imported archive, the keys have to be entered into the RM 
prior to first over-the-air delivery. 

NOTE: The initial retrieval or delivery over-the-air is not differential after importing an archive. For 
large codeplugs, it is recommended to perform a scheduled wired retrieval or delivery prior 
to the first over-the-air operation to minimize transfer time. 
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2.12.2.2.2 Entering Radio Identity Information 

Radios can also be entered one at a time into the RM Server. This requires the system 
administrator to know all identification information of the radio including the serial number, radio 
ID, common air interface ID (CAI), OTAP authentication key ID and OTAP authentication key 
value. 

2.12.2.2.3 Radio Identity File Importing 

If populating numerous radios at one time, a Radio Identity File may be used. The Radio Identity 
File is a Comma Separated Value (CSV) file that contains a list of radios each containing the serial 
number, radio ID, CAI, OTAP authentication key ID and OTAP authentication key value. An 
example file can be found in the RM install directory. 

2.12.2.2.4 Performing a Configuration Retrieval Operation 

The RM allows scheduling of multiple radio configurations to be retrieved unattended. The RM 
starts the retrieval at the scheduled time and continues until all selected radios are either 
complete, errored, or cancelled. It is recommended that over-the-air operations are scheduled 
during times of low traffic in order to minimize the impact on system performance. 

NOTE: After importing a radio into the RM Server, a scheduled over-the-air or wired retrieval 
operation is required. For large codeplugs, it is recommended to perform a scheduled 
wired retrieval or delivery prior to the first over-the-air operation to minimize transfer time. 

The retrieval mechanism over-the-air supports RM data and voice to coexist, although system 
performance may be degraded slightly. The mechanism can also handle radios that enter and 
leave RF coverage. The retrieval operation utilizes presence to optimize the delivery. 

2.12.2.2.5 Recommended RM Server Population Method 

There are numerous methods to initially populate the RM Server. Most dealers can quickly 
determine which method aligns the best with their standard practices. 

The following steps are considered the most optimal RM Server population method: 

I.Add a new radio with serial number. 

2. Schedule a wired read. 

3. Assign the proper radio ID, CAI, radio IP, OTAP authentication key ID and value. 

4. Select the appropriate radio template. 

5. Upgrade the template firmware if necessary. 

6. Schedule a wired delivery. 

After a successful wired delivery, the radio should be completely synchronized and ready for use 
on the system, and for its next over-the-air programming. These steps should be followed for each 
radio. 

If the RM Client, Server, and Device Programmer are all on the same computer, these steps can 
all be performed without disconnecting the radio from the computer. The Device Programmer 
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should be configured via a wired connection during these steps. If the selected template has 
Enhanced Privacy and/or Symmetric Keys enabled, the key values must be populated in order for 
the delivery to be successful. 

2.12.2.3 Modifying the Radio Configurations within the RM Server 

Once populated in the RM Server, the radio configurations are modified using the classic CPS 
interface. A radio entry in the RM Server references a configuration. The referenced configuration, 
referred to as a template, can be unique to the specified radio, or can be a configuration 
referenced by numerous radios. Radio identity information is specific to the radio, while other 
parameters in the template are shared. 

When a radio’s configuration is updated, the status gets updated to “Codeplug Modified”. This 
means that the configuration needs to be delivered to the radio over-the-air. 

If the radio user is allowed to make changes via the radio front panel, it is important to understand 
that these updates are not retained after a delivery. The configuration in the RM Server overwrites 
what is in the radio when delivered. Similar to how wired CPS functions today, the system 
administrator must read radios over-the-air first, make individual updates to each, and then deliver 
the new configurations in order for the previous changes to be retained. If using a single 
configuration (a template) for numerous radios, there is no way to retain any individual changes 
the radio users may have made. All radios are updated to match what is in the template, with the 
exception of the radio identity information. 

NOTE: Programming radios that are managed within the RM Server with an unmanaged wired 
CPS causes the radio to be out of sync with the RM Server. This causes the next over-the- 
air operation to take a longer time since the entire configuration must be retrieved or 
delivered. 

It is important to take special care when changing parameters that may break communication 
between the radio and the control stations used by the RM Server. For example, accidentally 
changing the frequencies of the channel used for OTAP communication results in the RM no 
longer being able to communicate with that radio. The radio must be programmed via the wire in 
order to recover. 

If changing parameters such as radio ID and OTAP authentication key ID and value over-the-air, 
the previous known values are used to deliver the new values. If these values become out of sync 
(possibly due to an unmanaged wired write of a radio), the Reset Identifiers feature should be 
utilized. Reset Identifiers allows the values used to communicate with the radio (in contrast to the 
new values) to be set within the RM Server. If these values are unknown, the radio must be 
programmed via the wire in order to recover. 

2.12.2.4 Delivering the Modified Radio Configurations to the Radios 

Once the updates have been made to the radio configurations within the RM Server, their status 
gets updated to “Codeplug Modified”. This means that the configuration needs to be delivered to 
the radio over-the-air. 

The RM allows scheduling of multiple radio configurations to be delivered over-the-air unattended. 
The RM starts the delivery at the scheduled time and continues until all selected radios are either 
complete, errored, or cancelled. It is recommended that over-the-air operations are scheduled 
during low traffic in order to minimize the impact on the system performance. The delivery 
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mechanism over-the-air allows for voice to coexist with the RM data, although system 
performance may be degraded slightly. The mechanism can also handle radios that enter and 
leave RF coverage. It utilizes presence to optimize the delivery. 

The time it takes to deliver a configuration to a set of radios is dependent on the number of radios 
and the amount of changes to the configuration currently in the radio. 

A pacing option is available to add additional delay to the delivery process. This is useful when 
delivery time is not important and it is desirable to minimize impact on the system performance. 
The pacing option is set to zero unless manually changed in the RM Device Programmer. 

2.12.2.5 Applying (or Switching Over) the Delivered 
Radio Configurations 

A delivery has an option to simply deliver the new configuration without applying it, or to apply it 
immediately after delivery. Applying the configuration is known as a “switchover”. When changing 
critical communication parameters, it is recommended that the new configuration is 
delivered to all the radios first, and then a separate switchover is delivered to the same set 
of radios. This minimizes the downtime by applying all configurations at the same time. If making 
minor changes to the configuration, for example address book entries or button configurations, it is 
acceptable for each radio to apply the changes immediately as they are delivered. Although the 
first radio may end up receiving the address book before the last radio, there would be little impact 
on the system operation. In contrast, if updating a critical communication parameter like transmit 
or receive frequency, the first radio is out of communication with the last radio until the last radio 
receives its programming. 

2.12.2.5.1 Delay Option and the Switchover Tinner 

A configuration switchover has the option for a max delay timer, also known as the switchover 
timer. The switchover timer is the maximum duration the radio waits after receiving the switchover 
message before performing the switchover. 

If the switchover timer is set to zero, there is no prompt at the radio, and the switchover occurs 
immediately upon receiving the switchover message. If the value is greater than zero, the radio 
user receives a prompt to accept or delay the switchover. If accept is selected, the radio 
immediately resets and applies the changes. If there is no selection or a delay is selected, the 
radio continues to operate on the old configuration until the switchover timer expires, at which time 
the radio resets and applies the changes. If in an emergency or in a voice call when the switchover 
timer expires, the radio delays the switchover until the emergency is cleared or the voice call is 
over. If at any time while the switchover timer is running and the radio user cycles power, the 
configuration is applied on power up. 

Because radio users have the option to accept or delay, it is not recommended to have a 
large switchover timer when changing critical communication parameters. Otherwise the 
first radio applies its changes well before the last and results in possible communication 
disruption. 
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2.12.2.5.2 Presence Registration Suppression 

If switching over many radios independent of the delivery and utilizing a zero value switchover 
timer, the radios may be reset within a short duration of each other. This may result in radios 
sending their presence registration, also known as their automatic registration service (ARS) 
message, within a short duration of each other, which may result in channel blocking. There is an 
option available in the RM to enable or disable the radio from sending a presence registration 
immediately after a switchover. 

If making changes to the radio configuration that does not affect the channel assignments, like 
address book entries or button layout, it is not necessary to re-register with the DDMS. Therefore 
presence registration can be suppressed after a switchover. 

If making changes to the radio configuration that affects the channel assignments, like adding, 
changing or removing channels, it is necessary to re-register with the DDMS. Therefore presence 
registration should not be suppressed after a switchover. 

If making changes to the presence server address, the presence should not be suppressed. 

2.12.2.5.3 Access to the Last Modified Date and Time via the Radio Menu 

The radio user can access the radio menu to see the date and time the configuration was 
modified. This represents the date and time the codeplug package was compiled by the device 
programmer just prior to delivery. 
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2.13 Voice Operated Transmission (VOX) 

MOTOTRBO provides the ability for hands-free radio transmissions with select radio accessories. 

2.13.1 Operational Description 

Voice Operated Transmission (VOX) monitors the accessory microphone for voice activity. When 
voice is detected, the radio is keyed-up and the voice is transmitted. When voice is no longer 
detected at the accessory microphone, the radio is de-keyed. 

2.13.2 Usage Consideration 

There are several considerations that should be made when VOX is used. First, VOX is designed 
to key-up and transmit whenever voice is detected. This means that every time the operator 
speaks the radio will transmit. If the radio operator is in close proximity to another person, the radio 
may detect the other person’s voice and begin transmitting. The successful use of VOX requires 
the radio operator to be aware of any possible audio sources that may inadvertently cause the 
radio to transmit at an undesirable time. 

Second, the use position of the VOX accessory is an important factor in using VOX successfully. 
The radio operator should position the accessory so that it can pickup the operators voice with a 
minimal amount of ambient noise. 

Additional consideration is needed as outlined in the following sections. 

2.13.2.1 Suspending VOX 

In those situations when VOX may not be desired, the radio operator can temporarily suspend 
VOX by pressing PTT. The radio will immediately suspend VOX and key-up the transmitter. 
Traditional (i.e. non-VOX) radio behavior will be used for any following transmissions. VOX 
operation will be resumed if the channel is changed (and changed back), the radio is power 
cycled, or the user re-enables VOX using the menu or a designated programmable button. 

To disable VOX on a channel so that VOX behavior does not resume after a power-cycle or 
channel change, the menu or the designated programmable button must be used. 

2.13.2.2 Talk Permit Tone (TPT) 

When VOX is used in conjunction with the Talk-Permit-Tone (TPT), the expected behavior of the 
radio should be understood. When TPTs are disabled the radio operator may begin speaking and 
the radio will immediately key-up and transmit the entire phrase uttered by the radio operator. 
However, when TPTs are enabled the radio operator must use a trigger word to key-up the radio. 
The trigger word will not, in most cases, be transmitted. After uttering the trigger word, the radio 
operator should wait until after the TPT is heard to begin speaking. 
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2.13.2.3 Emergency Calls 

When a radio operator presses the Emergency Alarm button on a VOX-enabled channel, VOX is 
temporarily suspended so that the radio operator can handle the emergency situation. VOX 
operation will automatically resume once the emergency has been cleared. If at any time during 
the emergency the radio operator presses PTT, VOX operation will not automatically resume after 
the emergency is cleared. See “Suspending VOX” on page 149 for instructions on how to resume 
VOX. 

2.13.2.4 Transmit Interrupt 

Because of the long delay involved with interrupting a voice transmission that translates to large 
amounts of audio truncation in a radio configured for VOX operation, VOX is not compatible with 
the Transmit Interrupt features (specifically, Voice Interrupt and Emergency Voice Interrupt). 
Accordingly, for a radio that is provisioned to transmit interruptible voice, VOX is prevented from 
operating. Radios should not be provisioned with VOX and either Voice Interrupt or Emergency 
Voice Interrupt features on the same channel. 

2.14 Lone Worker 

For a radio user who is operating machinery, carrying out a security patrol or working in a plant 
alone, the Lone Worker feature provides a way to remotely monitor, if a user has stopped activity. 

The Lone Worker feature is a predefined timer reset with user activity. For example, if the activity 
timer is set for 10 minutes and the user has no interaction with the radio during this time, the 
inactivity timer expires and a pre-warning tone sounds immediately after 10 minutes. If the user 
fails to reset the timer by an interaction with the radio (such as a button press, PTT, volume knob 
turn, etc.), the radio initiates Emergency. For more information, see section 2.3.4 “Digital 
Emergency”. 

The Lone Worker feature is available for both the portable and mobile radios, and in analog and 
digital modes. 
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2.15 Bluetooth® Support 

The MOTOTRBO radio subscriber supports the Bluetooth Headset Profile (HSP), Bluetooth 
Personal Area Networking (PAN) profile for Bluetooth IP networking to a PC, and Serial Port 
Profile (SPP) for communication with Commercial Off-the-Shelf (COTS) Bluetooth Headset, 
Bluetooth Barcode Scanner, Motorola Bluetooth Headset with remote PTT, and Motorola Bluetooth 
PTT Only Device (POD). The radio subscriber supports up to four simultaneous Bluetooth device 
connections, one of each type. The types include HSP, SPP, PAN and Fast PTT. 

Example: The radio subscriber can connect to a Bluetooth headset, a Bluetooth scanner, a 
Bluetooth PAN PC and a Motorola Bluetooth POD simultaneously. 

2.15.1 Bluetooth Pairing and Connection 

Bluetooth operates within a range of 10 metres line-of-sight. This is an unobstructed path between 
the radio and the Bluetooth device. It is not recommended to leave the radio behind and expect the 
headset to work with a high degree of reliability when they are separated. At the fringe areas of 
reception, both voice and tone quality may start to sound “garbled” or “broken”. To correct this 
problem, simply position the radio and headset closer to each other to re-establish clear audio 
reception. 

For pairing with multiple Bluetooth devices, it is recommended to pair with data devices such as 
the scanner and/or Motorola POD, before the headset. If the headset is paired first and activates 
the audio link, the audio link delays and/or interferes with subsequent pairings between the radio 
and additional Bluetooth devices. In some scenarios, pairing to additional devices may time out 
and fail due to audio link interferences, requiring attempts for reconnection. Hence pairing with 
data devices prior to the headset provides a better pairing experience. 

In order to allow other Bluetooth devices such as the PC to discover and pair with the radio, place 
the radio in Bluetooth “Find Me” mode. The radio can enter this mode through the user menu in the 
display model, or via a programmable button on the non-display model. 

2.15.1.1 Pairing a Bluetooth Device with Display Radios 

Pairing a device with a display radio is a user-initiated action. Basically, turn on the Bluetooth 
device and place it in pairing mode. Use the “Find Devices” option under the Bluetooth menu to 
locate available devices. Some devices may require additional steps to complete the pairing. Refer 
to the respective devices’ user manuals. Upon successful pairing, the radio display and tone 
indicators will alert the user of an established connection. 

NOTE: If the Bluetooth device requires pin authentication, the user will be prompted to enter the 
pin code via the keypad, to establish a connection. 

2.15.1.2 Pairing a Bluetooth Device with Non-Display Radios 

Pairing a device with a non-display radio is also a user-initiated action. Turn on the Bluetooth 
device and place it in pairing mode. Use the preprogrammed Bluetooth button on the radio to 
connect to the device. The LED blinks yellow and a tone sounds when a connection is being 
established. Upon successful pairing, a positive tone will alert the user of an established 
connection. 
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NOTE: If pin authentication is required for pairing, the pin codes should be preprogrammed into 
the non-display radios via CPS. 

2.15.2 Bluetooth Headset/PTT and Radio Operation 

2.15.2.1 Radio Operation with COTS Headset 

When the radio and COTS headset are paired and connected via user selection through the 
display radio user interface, the radio sends ring indications to the headset to indicate the start of 
an incoming audio call setup. The incoming call can be accepted by pressing the multi-function 
button on the headset; the audio link is set up between the radio and headset for communication. 
Once the Bluetooth audio link is connected, the Bluetooth microphone/speaker is used as the 
active audio path for voice communication. When the radio receives an incoming voice 
transmission, the incoming audio is routed to the Bluetooth headset speaker. When the radio PTT 
is pressed, the radio initiates an outgoing voice transmission with the headset microphone audio. 
The radio treats the headset microphone audio similar to the internal radio microphone audio for 
outgoing call transmissions. 

For portable radios, the active Bluetooth audio path can be switched on/off from the radio user 
interface via menu, or programmable button. For mobile radios, the active Bluetooth audio path 
can be switched on/off via the on/off hook. 

The audio path automatically switches from the Bluetooth headset to the radio when the headset 
disconnects either intentionally or accidentally, or when the headset battery is dead. Otherwise, 
the user can manually press the multi-function key of the COTS headset to switch to the radio 
audio path. 

2.15.2.2 Radio Operation with Motorola Headset/PTT 

For Motorola Bluetooth headsets equipped with a remote PTT, the remote PTT can be used to 
initiate outgoing voice transmissions. The audio path will be set up to the headset audio path after 
the connection to the headset/PTT is established. 

2.15.2.3 Radio Operation with Motorola PTT Only Device (POD) 

Additionally, the radio supports the Motorola Bluetooth POD for initiating voice communication. 
This device can be connected and used independently with the radio, or could also be used in 
conjunction with a Bluetooth headset connected to the radio. The remote POD is used to initiate 
outgoing voice transmissions. The behavior of pressing the POD has an identical operation to 
pressing the radio PTT button - with respect to audio transmission and routing. 

This device is not equipped with a local microphone or speaker; the Bluetooth headset or radio 
microphone/speaker will be used for audio communication. 
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2.15.3 Bluetooth Barcode Scanner Operation 

After the radio and a Bluetooth barcode scanner are paired and connected as a SPP serial device 
via user selection through the radio user interface, the scanned data sent from the scanner to the 
radio could be routed to the option board, or to a remote radio via the over-the-air interface. The 
routing of the data to the option board or to the remote radio is configurable via CPS. Sending the 
data from the radio via the over-the-air interface to the remote radio is supported in digital mode 
only. The security support for over-the-air interface transmission is limited to the radio’s Enhanced 
Privacy support. Routing of data from the radio to the option board is supported in both analog and 
digital mode. 

2.15.4 Bluetooth Personal Area Networking (PAN) Operation 

The radio supports the Bluetooth PAN as an access point. The remote Bluetooth PAN device, for 
example a PC should be connected to the radio as a PAN client. After the radio and the remote 
Bluetooth PC client are paired and connected with the PAN profile, an IP network connection will 
be established for IP datagram communication. All data communication between the radio and 
Bluetooth PC client should be addressable with IP address and application port number over the 
Bluetooth PAN connection. 

If a large amount of data needs to be communicated between the radio and the PC application, it 
is recommended to disconnect any Bluetooth headset and other Bluetooth devices from the radio. 
The PAN connection data communication can slow down greatly if any devices of other Bluetooth 
profiles are connected. 
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2.15.5 Recommended Bluetooth Devices 



Below is a table of COTS Bluetooth devices (headset, PTT and scanner) recommended by 
Motorola for use with the MOTOTRBO radios. Only these Bluetooth devices have been tested, 
validated and qualified for many quality attributes such as audio, size, weight, comfort, battery life, 
interoperability, to meet customer expectations. This table may change in the future to include 
more devices. 

It is not recommended to use any Bluetooth device which is not listed below. The following are key 
considerations when selecting a device: 



1. A Bluetooth device with enhanced audio processing, and 

2. A headset that supports disconnecting/reconnecting the active audio link to the radio by 
pressing/releasing the multi-function button. This maximizes headset battery life. 



Model 


Description 


89409N 


Motorola HK200 Operations Critical Wireless, 128-bit Encryption, 
Commercial Secure Simple Pairing (SSP) version 2.1 


NNTN8125 


Motorola Bluetooth Wireless Accessory Kit, STD Pairing, 12" Cable 


NTN2572 


Motorola Bluetooth Accessory Earpiece with 12" Cable 


NNTN8143 


Motorola Bluetooth Wireless Accessory Kit, STD Pairing 


NNTN8126 


Motorola Bluetooth Wireless Accessory Kit, STD Pairing, 9.5" Cable 


NTN2575 


Motorola Bluetooth Accessory Earpiece with 9.5" Cable 


Symbol CS3070 


COTS Symbol Barcode Scanner 



2.15.6 Avoiding Accidental Connection 

The Bluetooth headset is usually assigned to one person. However, the two-way radio may not be 
assigned to a person; it could be shared by different people such as retail sales associates, 
housekeeping, security and others. If a Bluetooth headset was paired with a radio, the headset 
automatically reconnects to the same radio the next time it powers on. 

Scenario: If the same radio has been assigned to a different user, the headset can accidentally 
reconnect to the wrong radio belonging to a different user. Automatically, the previous user still 
receives a positive pairing indication from the headset. 

To avoid accidental connection as described in the above mentioned scenario, follow the 
instructions below: 

• For HK200: Erase all pairing information from the headset by pressing and holding the 
volume button and call button together, followed by turning on the headset. When this 
procedure is performed, the headset does not initiate connection to any remote device 
automatically. 

• For Motorola Headset/PTT and POD: Erase all pairing information from the device by 
pressing and holding the PTT button followed by turning on the headset. When this 
procedure is performed, the headset or POD does not initiate connection to any remote 
device automatically. 
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2.16 One Touch Home Revert Button 

This feature is available for mobile radios in both analog and digital modes. The customer can 
program a button as the “Home Revert” button via the CPS. This button allows the user to jump to 
a pre-assigned “Home” channel. The CPS does not allow a customer to select a channel in the 
“Channel Pool” 1 to be the Home Revert Channel. 

2.17 Password and Lock Feature (Radio Authentication) 

MOTOTRBO provides a password-based locking mechanism to protect radios from unauthorized 
users. This feature can be enabled and the password can be changed both via the CPS or the 
radio menu. 

With this feature enabled, a radio prompts the user to enter a four-digit password on powering up. 
After three incorrect password attempts, the radio enters a locked state for 15 minutes. No calls 
(including Emergency Calls) can be placed or received, when a portable radio is in locked state. 
Upon correct password entry, the radio enters normal operation mode. 

The password input method varies according to the radio display models. For example: 

• On a non-keypad portable, a user inputs the password via a combination of the Channel 
Switch and Side Button(s). 

• On a non-keypad mobile, a user inputs the password via a combination of the Channel 
Knob and Front Button 2. 

• On a keypad mobile, a user inputs the password either with the Accessory Keypad or via 
a combination of the Channel Rocker button and the <OK_Button>. 

If a Foot Switch is configured to initiate an emergency and the radio is powered up using the Foot 
Switch, the radio skips the password input procedure. Upon completion of an emergency, the radio 
then initiates the password authentication if this feature is enabled. 

If a user presses the test mode series button when the radio is locked or in password input state, 
the radio skips the password authentication and enters test mode. 



1. The “Channel Pool” is a zone for keeping all the trunked and Data Revert Channels. 
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2.18 Digital Telephone Patch (DTP) 

The MOTOTRBO Digital Telephone Patch is a Motorola proprietary feature introduced in software 
version R01 .08.00 supporting two types of phone patch calls: 

• Individual Phone Patch Call - This allows a half-duplex voice communication between 
a radio user and a phone user. This communication can be initiated from either party. 

• Talkgroup Phone Patch Call - This allows a half-duplex voice communication between 
a phone user and a group of radio users. This type of communication can be initiated 
only by the phone user. 

This feature is supported in Single Site, IPSC LACs, IPSC WACs, and Capacity Plus 
configurations. This feature is supported in display and non-display radios. However, for non- 
display models, phone numbers, over dial or access/de-access codes need to be configured 
manually to the programmable buttons because the radios do not have a keypad. 

The DTP feature utilizes Commercial Off-the-Shelf (COTS) Analog Phone Patch (APP) boxes, and 
is compatible with any DTMF-based APP box that supports the 4-wire interface and can 
communicate in half-duplex mode. The Zetron 30 (Worldpatch) and PL 1877A (MRTI2000) are two 
examples. Most APP boxes in the market support the following telephony services: 

• Access and De-access Codes 

• The access code is used to wake up the APP box, and prevent the radio user or 
phone user from making unauthorized phone patch calls. 

• The de-access code is used to terminate the phone patch call if an access code is 
required when setting up the call. 

• Different access code/de-access codes may be configured to have different privileges, 
so the codes can be used to block/allow radio from performing a call type. 

• Phone Usage Time-Out Timer (TOT) - The APP box ends the call once the timer 
expires. 

• A go-ahead tone is emitted to the phone user when the radio user de-keys. This 
provides an indication to the phone user to begin talking. 

• Direct connection to the PBX or PSTN line 

• Type Approvals for Supported Countries 

Instead of recreating such services in the radio system, this feature relies on the APP box to 
provide these services. The APP Box is connected to the MOTOTRBO repeater via the 4-wire 
interface. The phone patch feature utilizes APP boxes that are connected to the repeater, hence 
this feature is only available in repeater mode, but not direct mode. 

2.18.1 Phone Call Initiation 

It can be configured via CPS to allow a radio to initiate or receive phone calls on per digital 
personality basis. Only phone-enabled radios can initiate and receive a phone call. 
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2.18.1 .1 Call Initiation by a Radio User 

When a radio user initiates a phone call, the channel access is always polite (even if configured as 
impolite), regardless of the radio’s programmed admit criteria. This is analogous to sending CSBK 
or data signaling, which is sent politely. 

When a radio enters a phone call, a phone call text string and icon shows up on the display screen 
to alert the radio user. 

Buffer dial is supported for access/de-access code, phone number, and over dial digits. “Buffer 
Dial” means that the radio user enters the digits from the radio keypad, then presses the “OK” 
button to send out the digits as in-band audio. The phone number can be 22-digits long or less. 
Before calling a phone user, the radio user switches to the channel that is capable of a phone 
patch call, and uses one of the following dialing methods: 

• Manual Dial - Enter the phone number from the radio keypad manually. This option can 
be enabled or disabled on the radio via CPS. 

• Phone Address Book - Select a phone number from the radio’s Phone Address Book. 

• One Touch Button - Push a programmable button of the radio. The one touch button is 
associated with a phone number from the Phone Address Book. 

If an access code is required for phone calls, it could be configured in the radio or entered by the 
radio user manually. When the access code is not configured in the radio, the radio user is 
prompted to manually enter the access code after dialing the phone number. If access code is not 
required, the radio user can skip this step by not keying anything. After the radio user sends out 
the phone number and access code, the phone rings and the user can answer the call. 

If there is an Interactive Voice Response (IVR) device at the phone user’s end and over dial is 
required, the radio user can enter the over dial digits via the radio keypad or a programmable 
button. 

Example: The IVR device at a bank may prompt the user to enter the account number to access 
account information. 

2.18.1.2 Call Initiation by a Phone User 

When a phone user initiates the call, the phone user dials the phone number of the APP box, or 
the PBX box, if a PBX is used. The PBX then connects the call to the APP box. If access code is 
required, the phone user enters the access code following the audible prompt from the APP box. 
After the APP box validates the access code, the box connects the call to the repeater. The 
repeater sounds a tone and prompts the phone user for the target ID. Then, the phone user enters 
the target ID to reach the radio user/group. 

NOTE: If a Go-Ahead tone is configured in the APP box, the phone user hears the tone for the 
Target ID, followed by the Go-Ahead tone. 

The length of the target ID is configurable via CPS, and the format varies according to different 
system configurations. 

• Single Site and IPSC - The target ID includes the call type, channel slot number, and the 
radio/talkgroup identifier. 
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• Capacity Plus and LCP - The target ID only includes the call type and the radio/talkgroup 
identifier; the channel slot number is not required. 

When keying in the target ID, the phone user may try up to three times maximum, after which the 
system terminates the call automatically if no valid target ID is received. After the repeater 
validates the target ID, if the channel is busy, the repeater sounds a busy-waiting tone to the 
phone user and waits for the channel to become idle, before resuming the call setup. While waiting 
for the channel to become idle, the phone user hears the busy-waiting tone, and can choose to 
wait or end the call. If the channel does not become idle for a configurable period of time, the 
repeater ends the call setup. In this scenario, the phone user stops hearing the busy-waiting tone 
and hangs up the call. If the channel is idle or becomes idle before the timer expires, the repeater 
alerts the called radio user/group by ringing tones. 

A radio user can join a phone call from a phone user while scanning for activities on the phone 
channel except in Capacity Plus/LCP where scanning is not supported. 

For individual phone calls, the target radio user answers by pushing the PTT before the call can be 
set up completely. For talkgroup phone calls, it is configurable in the repeater via CPS to allow a 
target radio user to answer the call by pushing the PTT before the call can be set up completely. 
When answering is not required, the phone user can talk immediately after the first ring. When 
answering is required, the phone user is not permitted to talk until one of the target radio users 
answers the call by pushing the PTT. Otherwise, the phone user is not heard by the radio users. 
When answering is required but the call is unanswered during the configured response period, the 
repeater sends a de-access code to the APP box, and the call ends automatically. 

Phone All Call, an exclusive phone talkgroup call, is supported in the DTP feature as well. The 
phone user can follow the same phone talkgroup call setup procedure to set up the phone call by 
using the All Call ID or Os as the Target ID. In a Phone All Call, the phone user can start to talk 
after the first ring, before any radio user answers the call. During a Phone All Call, not all radio 
users are able to respond to the phone user. Only radio users with radios configured with All Call 
announcement capability are able to respond to the landline phone user and heard by all the other 
radio users. These users are able to end the Phone All Call by sending the de-access code. 
Hence, when a phone user makes a Phone All Call, it is recommended to provide contact 
information so that the receiving radio users have means to contact the phone user if needed. 
Phone All Call can be enabled/disabled in the repeater via CPS. 

Pre-Configured Target ID: For any system configuration (Conventional Single Site, IPSC, 
Capacity Plus and LCP), a default target ID may be pre-configured in the phone gateway repeater. 
This is an optional configuration and can be enabled/disabled via CPS. When enabled, if the 
phone user does not enter the first digit of the target ID within 3 seconds (3-seconds rule) after 
hearing the target ID prompt tone, the pre-configured target ID will be used for the phone call 
automatically and the system will start to ring the target user or user group. If the target ID entered 
by the phone user is invalid and a re-try is needed, the same 3-seconds rule will be applied in each 
retry. The pre-configured target ID can be an individual radio user, or a user group, or an All Call. 

2.18.2 During a Phone Call 

During a phone patch call, the radio user in the phone call has higher channel access priority than 
the phone user, allowing the radio user to key up and talk impolitely over a phone user regardless 
of the radio’s in-call permit criteria configuration. However, if a phone user needs to talk, the phone 
user has to wait until the radio user dekeys. Otherwise, the phone user will not be heard by the 
radio users. 
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When another radio user is talking in a phone talkgroup call, the radio user follows the radio’s In 
Call Criteria configuration with the exception of using the Follow Admit Criteria when the In Call 
Criteria is provisioned with Transmit Interrupt. 

NOTE: This is because Transmit Interrupt is not supported in the phone call. 

When detecting an impolite takeover from a radio that is not partied to the phone call or an 
emergency on the phone patch channel during a phone call, the repeater automatically ends the 
phone call by sending a de-access code to the APP box. 

During a phone call, if a radio drops out of the call due to various reasons (for example; out-of- 
range), the radio can make a late entry back into the call if it is a talkgroup call. If it is an Private 
Call, the radio can make a late entry back to the call in Conventional Single Site or IPSC. However, 
late entry is not supported in a Capacity Plus system configuration if a radio fades out of an Private 
Call completely. 

There are three switches that happen during a call: 

• Radio-to-Phone switch - The radio user finishes talking and dekeys, then the phone 
user starts to talk. 

• Phone-to-Radio switch - The phone user talks while a radio user keys up and starts to 
talk. 

• Radio-to-Radio switch - The radio user finishes talking and dekeys, while another 
radio user keys up immediately and starts talking. This switch only takes place in 
talkgroup calls only. 

To ensure a smooth switch and avoid voice truncation, the Enhanced Channel Access feature is 
introduced to minimize the switching impact and to achieve the best overall user experience in all 
system configurations. As a result, only minimum additional Voice Access Time is introduced for 
the switches. The performance parameters are summarized in the table below. 



Additional Voice 
Access Time (ms) 


Single Site 


IP Site Connect 


Capacity Plus 


Min 


Mean 


Max 


Min 


Mean 


Max 


Min 


Mean 


Max 


Radio-to-Radio / 
Phone 


60 


210 


360 


60 


210 


360 


60 


210 


360 



* All time figures are increases to existing Voice Access Time 



A phone call is clear regardless of whether privacy/Enhanced Privacy is enabled in the radio or 
not. Transmit Interrupt is also automatically disabled for the phone call. 

When a radio is in a phone call, there are visual ergonomic indications to show that the radio is 
currently in a phone call. A text string and icon appearing on the radio display indicates that it is 
currently in a phone call. 

2.18.3 Ending a Phone Call 

A phone patch call can be ended by either the radio user, phone user, or the APP box, with the 
following methods: 
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• The radio user may push the back button, or a programmable exit button to end/reject 
the call. Alternatively, the de-access code can be sent manually from the keypad. 

• The phone user ends the call simply by hanging up, or by sending the de-access code 
from the keypad. Sending the de-access code is recommended, because this method 
allows the radio system to end the call immediately, thus letting the radio users know 
that the call is ended in the correct manner. However, if the phone user ends the call by 
hanging up, this depends on when the APP box responds to the PSTN disconnecting 
signaling. Some APP boxes may not be able to detect PSTN signals and therefore waits 
for the TOT to expire. Hence, ending the call in this manner normally takes a longer 
time. 

• Additionally, if a phone TOT is configured in the APP box, the call is ended by the APP 
box automatically when the call duration exceeds the timer. Some APP boxes provide 
configurable 30-second warning/alert tones before the timer expires. 

When the phone call ends, the text string and icon on the radio screen disappear. This is followed 
by a “phone exit” tone from the radio, to alert the user that the radio has been disconnected from a 
phone call. 

The phone patch feature works similarly in all MOTOTRBO system configurations, except some 
minor differences in specific system configurations. The following subsections describe the minor 
differences in each particular system configuration. 

2.18.4 Digital Telephone Patch System Configuration 

2.18.4.1 Phone Patch in Single Site and IP Site Connect 
Local Area Channels (LAC) 

In Single Site, the system can support only one phone call per repeater because a repeater can 
only be connected to one APP box. The phone call utilizes either channel of the repeater one at a 
time, and the selection of the channel, is the choice of the party initiating the phone call. This could 
be the radio user or the phone user. The other unused channel can be used for other voice or data 
services. Legacy or third-party radios are not able to join in the phone call because this is a new 
Motorola proprietary feature. 

The phone patch call on an IPSC LAC works similarly as the phone patch call in a Single Site 
channel. The target ID includes the call type (Talkgroup “8” or Individual “7”), the channel (slot 1 or 
2), and the radio or talkgroup identifier. 

Example: The phone user is instructed to dial the phone number associated with the Phone Patch 
box, and then prompted to provide the target ID to reach a radio user. The phone user 
dials extension 710020 after the beep, which initializes an Private Call on channel 1 to 
radio 20. To contact an entire talkgroup, the phone user dials extension 820100, which 
initializes a talkgroup call on slot 2 to talkgroup 100. 





System Feature Overview 



161 



The following figures describe the typical phone patch topologies in Single Site configuration and 
IPSC LACs. 



Local 
Channel 1 



Local 
Channel 2 



I 



Figure 2-49 Phone Patch Topology in Single Site Configuration 




Figure 2-50 Phone Patch Topology in IP Site Connect Local Area Channel Configuration 
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2.18.4.2 Phone Patch in IP Site Connect Wide Area Channels (WAC) 

In IP Site Connect (IPSC), wide area channels include channels from multiple repeaters. However, 
since a WAC can host only one call at a time, it is designed that a WAC can support only one APP 
box that can be connected to any repeater on the WAC. The phone patch call can be initiated from 
any site, but it always goes through the only APP box supported on the WAC. 

NOTE: The target ID includes the call type, the channel, and the radio or talkgroup identifier. 

Legacy or third-party radios are not able to join in the phone call because this is a new Motorola 
proprietary feature. 

The following figures describe the typical phone patch topologies in IPSC. 
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Figure 2-51 One APP Box Supporting Two Wide Area Channels in IP Site Connect 



Site A 



1 



I 






WAC 1 

















WAC 2 


J Radio 2 


— 



Radio 1 



MOTOTRBO 

Radios 



la ® 



PSTN 



COTS Phone Pate 



Site B 



WAC 1 
WAC 2 



T 

Radio 3 



i 



Radio 4 



MOTOTRBO 

Radios 




COTS Phone Patch 




PSTN 



Figure 2-52 Two APP Boxes Supporting Two Wide Area Channels in IP Site Connect 
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Figure 2-53 APP Boxes Supporting Wide Area Channels and Local Area Channels in IP Site Connect 
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2.18.4.3 Phone Patch in Capacity Plus 

In Capacity Plus, because a repeater can only be connected to one APP box, the system can 
support one phone call per repeater. The phone call only uses one channel; the other channel can 
be used for other voice or data services. Any voice repeater can be used for phone calls, hence 
the maximum number of APP boxes that can be supported in a Capacity Plus system is equal to 
the number of voice repeaters in the system. 

The target ID includes the call type, and the radio or talkgroup identifier. The channel ID is not 
required because the system automatically selects the channel for the phone call. 

When the radio user initiates a phone call, if the rest channel is idle and phone capable for this 
radio, the phone call starts on the rest channel. If the rest channel is not phone capable for the 
radio, the phone call starts on an idle channel that is phone capable. 

When a phone user calls a radio user/group, the user dials the telephone number of the APP box. 
The phone call can start on either idle channel of the repeater that the APP box is connected to. 
Then the following rule is in order - If a channel is the rest channel, the phone call starts on this 
channel; if neither channel is the rest channel, channel 1 has a higher priority than channel 2. 

Legacy or third-party radios are not able to join in the phone call because this is a new Motorola 
proprietary feature. 

The following figure describes the typical phone patch topology in Capacity Plus. 




COTS Phone Patch MOTOTRBO lan 
Repeaters 

Figure 2-54 Phone Patch Topology in a Capacity Plus Configuration 



2.18.5 Wireline Telephony 



Also, with supported 3 rd party telephony applications, a wireline telephony solution is available in 
all MOTOTRBO system configurations (Conventional Single Site, IPSC, Capacity Plus and LCP) 

via Network Application Interface (for voice). The wireline telephony is illustrated as below: 
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Figure 2-55 Wireline Telephony with 3 rd Party Telephony Application 

The wireline telephony solution provides the same set of functionalities and similar user 
experience as the DTP solution that uses the APP box. The only difference is that the wire line 
solution does not use the APP box, instead, it uses a 3rd party telephony application. 
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2.19 Voice Announcement Feature 

MOTOTRBO 2.0 radio products support the voice announcement feature suite to audibly convey 
information to the radio user. An example of when this feature is helpful is when the MOTOTRBO 
radio display or indicators are not easily accessible (e.g. located under protective clothing) or 
when radio operator cannot be distracted from their task to look at the display or indicators. 

The voice announcement feature is supported in both analog and digital operation. The voice 
announcement feature includes a standard feature set and a premium feature set. The standard 
feature set and premium feature set are mutually exclusive (i.e. only one may be enabled). The 
voice announcement priority configuration determines whether radio traffic and alert tones may 
interrupt a voice announcement. The MOTOTRBO radio operator can enable or disable the voice 
announcement feature as appropriate for their work environment. 

The standard feature set uses pre-recorded voice announcement files that are loaded into the 
MOTOTRBO radio. A selection of professionally recorded voice announcement files is included 
with the MOTOTRBO Customer Programming Software (CPS). In addition, users may record their 
own voice announcement files 1 and load them into the MOTOTRBO radio. For example, to create 
a meaningful channel announcement (e.g. Maintenance Channel instead of Channel 4) or when 
the available voice announcement files do not match the language or dialect of the end users. 

The premium feature set generates the voice announcement using a speech synthesis algorithm 
in the MOTOTRBO radio. The MOTOTRBO CPS supports configuration of a custom dictionary to 
ensure accurate readout of abbreviations and industry specific terminology. The MOTOTRBO 
CPS loads the selected voice file 2 into the MOTOTRBO radio. The premium feature set supports 
read out of received text messages and job tickets. The radio management integration is seamless 
because the audio is generated in the MOTOTRBO radio. 



Feature Name 


Standard Feature Set 


Premium Feature Set 


Channel Alias Announcement 


Yes 


Yes 


(128 Channels Maximum) 


(Unlimited) 


Zone Alias Announcement 


Yes 


Yes 


(20 Zones Maximum) 


(Unlimited) 


Configurable Voice Announcement 
Priority 


Yes 


Yes 


Programmable Button Feature 
Announcement 


Yes 


Yes 


Programmable Button Feature State 


Yes 


Yes 


Multiple Language Support 


Yes 


Yes 


Text Message Readout Support 


No 


Yes 


Job Ticket Readout Support 


No 


Yes 


Voice Announcement Updates via 
Radio Management OTAP 


No 


Yes 



Table 19.1 Comparison of Standard vs. Premium Voice Announcement Features 



1 . The MOTOTRBO CPS software supports importing WAV files with the audio format of 8 bits per sample, 
8 kHz sampling rate, mono (single channel), and p-law encoding. 

A voice file consists of a language (e.g. English), regional dialect (e.g. American), and gender (e.g. male) 
that describe the generated voice. 



2 . 
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2.20 Analog Features 

For customers that are migrating from Analog systems to Digital systems, MOTOTRBO supports 
both analog and digital modes of operation. MOTOTRBO mobile and portable radios support both 
analog and digital modes (the user can select which mode to use, and change modes 
dynamically), while MOTOTRBO repeaters are configured to operate in digital mode or in analog 
mode. When in Analog mode, MOTOTRBO utilizes traditional FM technology, supports 12.5 
channel spacing, and can operate in repeater and direct modes. 
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2.20.1 Analog Voice Features 

The following traditional Analog features are supported by the MOTOTRBO system: 



Feature Name 


Description 


Time-Out Timer 


Sets the amount of time that the radio can continuously transmit before the 
transmission is automatically terminated. 


Squelch 


Special electronic circuitry added to the receiver of a radio which reduces or 
squelches, unwanted signals before they are heard through the speaker. 


Monitor/Permanent 

Monitor 


The user can check channel activity by pressing the Monitor button. If the 
channel is clear, the user hears static. If the channel is in use, the user 
hears the conversation. It also serves as a way to check the volume level of 
the radio, as while pressing the monitor button, the user can adjust the 
volume according to the volume of the static/conversation heard. 


Talka round 


This feature allows a user to talk directly to another unit for easy local unit- 
to-unit communications and bypass the repeater. 


12.5 kHz Configurable 
Bandwidth 


Channels on the radio can be programmed through the CPS to operate at 
12.5 kHz. 


PL/DPL 


Transmitted when the receiving radio is to only receive calls from radios with 
specific PL/DPL codes, this creates communications groups while operating 
in Conventional Dispatch mode. PL/DPL allows for more privacy on a 
frequency. PL/DPL is transmitted as a sub-audible frequency or a digital 
code. 


Channel Access Control 


This feature dictates what conditions a radio is allowed to initiate a 
transmission on a channel. There are three possible values which are 
Always, Channel Free, and Correct PL. Refer to “MOTOTRBO Channel 
Access” on page 22 for more details. 



2.20.2 MDC Analog Signaling Features 

MOTOTRBO contains a limited set of built-in MDC signaling features. These include: 



Feature Name 


Description 


Emergency Signaling 


Sends a help signal to a pre-defined person or group of people. The 
emergency feature also allows a user to sound an alarm or alert the 
dispatcher in an emergency situation. The user is also able to 
acknowledge an emergency. 


PTT-ID 


PTT-ID identifies the user’s outgoing calls on other users’ radios. 


Call Alert 


Call Alert notifies the radio user of incoming calls if they are a short 
distance away from their radio. Call Alert also informs unavailable users 
that someone is trying to reach them. 
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2.20.3 Quik-Call II Signaling Features 

The Quik-Call II signaling is used during analog mode of operation and encodes either single tone 
or a sequence of two tones within the audible frequency range (approximately 300 - 3000Hz). 
Encoding/decoding is particularly used for the Call Alert and Voice Selective Call features. 



Feature Name 


Description 


Voice Selective Call 


This feature allows announcement type messages to take place during a 
call to an individual or group of radios. This feature is used in systems 
whereby the majority of transmissions are between a dispatcher and a 
single radio. Voice Selective Call can be used to eliminate the need to 
listen to traffic that is irrelevant to the users. There are two distinct types 
of voice selective call - basic voice selective call and automatic voice 
selective call. 


Call Alert 


Call Alert notifies the radio user of incoming calls. This feature also 
informs the radio users when another radio user is trying to reach them. 
No voice communication is involved in this feature. 


Call Alert with Voice 


This feature is a combination of the Call Alert and Voice Selective Call 
features. Call Alert with Voice allows a receiving radio to receive voice 
messages and call alert signals. This feature is useful when a dispatcher 
needs to transmit a voice message and leave a Call Alert to the targeted 
radio. 
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2.20.4 Analog Scan Features 



Feature Name 


Description 


Nuisance Channel 
Delete 


A channel with unwanted activity is called a Nuisance Channel. The user 
can remove a Nuisance Channel from the Scan List temporarily by using 
the Nuisance Channel Delete feature. 


Priority/Dual Priority 
Scan 


Priority Scan allows a user to program the radio to scan more frequently 
transmissions on the most important channel, and ensure they do not 
miss critical calls. Dual Priority Scan allows a user to program a radio to 
frequently scan transmissions on the two most important channels, and 
ensure they do not miss critical calls. 


Tone Private Line 
Lockout 


During scan, if activity is detected on a channel, but does not match the 
un-muting condition, lockout occurs. Once lockout occurs, the radio 
ignores activity on that channel for the next nine scan cycles. However, if 
scan finds that activity has ceased on that channel, the counter is reset 
and is no longer ignored. 


Talkback Scan with 
Home Channel Revert 


Talkback scan allows activity on different communications channels to be 
monitored and answered. Home channel revert allows a user to 
automatically access a preferred channel. 



2.20.5 Analog Repeater Interface 

To facilitate the migration from analog to digital, the MOTOTRBO repeater offers an analog 
repeater interface that allows the repeater to operate with legacy analog accessories. 

The interface is configurable via the CPS and can support the following applications: 

1. Tone panels 

2. Phone Patches 

3. Console Desksets connected via a local interface 

4. Console Dispatcher in base station configuration 

5. Trunking controllers such as LTR and PassPort 

2.20.5.1 Analog Repeater Interface Settings 

The analog repeater interface is configurable via the CPS. The CPS offers repeater-wide settings 
as well as programmable input and output pins on the rear accessory connector. 
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2.20.5.1 . 1 CPS Repeater Wide Settings 



CPS Repeater 
Control Name 


Description 


Audio Type 


“Filtered Squelch” configures the repeater so that only the audible frequency 
spectrum (300 Hz - 3 kHz) is sent to the rear receive audio pin/speakers as 
well as transmitted over-the-air. The user in deskset controller applications is 
interested in this audible frequency spectrum. 

“Flat Unsquelch” should be used in applications such as trunking controllers or 
community repeaters where there is sub-audible signaling that needs to be 
passed. In this configuration, the repeater will pass the audio unfiltered over- 
the-air as well as to the rear receive audio pin and speakers. The filtering is 
performed in the external device, not in the repeater. 


Analog Accessory 
Emphasis 


Pre-emphasis is configurable on transmitting subscribers. In order to match the 
emphasis settings on the wireline, de-emphasis on the receive path and pre- 
emphasis on the transmit path of the analog repeater interface can be enabled 
or disabled. 

This setting is in addition to the repeater’s Emphasis setting. Furthermore, 
when Audio Type is set to “Flat Unsquelch”, there is no emphasis in the audio. 


Audio Priority 


This setting determines if “External PTT” or “Repeat Path” has priority over the 
transmitter when Disable Repeat Path is disabled. A priority of None implies 
the transmitter will be granted on a first come first served basis. 

*This feature is not supported for digital transmissions in Dynamic Mixed 
Mode; priority is on a first come, first served basis. 


Disable Repeat Path 


Some applications do not want the repeater to perform in-cabinet repeat; they 
warrant that the external PTT be the only input that can trigger the repeater to 
transmit. This setting configures the repeater to only transmit when the PTT is 
asserted. 

*This feature is not supported for digital transmissions in Dynamic Mixed 
Mode; digital transmissions from the radio are repeated regardless of Disable 
Repeat Path configuration. 
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2.20.5.1.2 Rear Accessory Port CPS Programmable Pins 

The rear accessory also has some pins that can be programmed to specific input/output functions. 
These pins can be programmed to either active high or low. 



CPS 

Programmable 

Pins 


Description 


PTT 


PTT can be programmed to any programmable pin on the rear accessory 
connector. 




In Dynamic Mixed Mode, if channel is busy when PTT is asserted on the 
repeater accessory port, then an audible channel busy alert tone is 
generated on speaker and Rx audio accessory pins. 


CSQ Detect 


Squelch detect will toggle this output pin on. Loss of squelch will toggle 
this output pin off. 




In Dynamic Mixed Mode, this pin is asserted ON on the repeater 
accessory port when: 

• Squelch is detected 

• The repeater is transmitting digital call (includes call transmission, call 
hang and channel hang time) 

• The repeater is transmitting exclusive CWID 




This pin is asserted OFF on the repeater accessory port when all of the 
above mentioned conditions are false. 


PL Detect 


A signal meeting the PL rules programmed in the channel toggles this 
output pin to its active state. Loss of the PL signal toggles the output pin 
to its inactive state. 




In Dynamic Mixed Mode, this pin is asserted ON on the repeater 
accessory port when: 

• PL detected 

• The repeater is transmitting digital call (includes call transmission, call 
hang and channel hang time) 

• The repeater is transmitting exclusive CWID 




This pin is asserted OFF on the repeater accessory port when all of the 
above mentioned conditions are false. 
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CPS 

Programmable 

Pins 


Description 


Monitor 


Asserting this input pin reverts the receiver to carrier squelch operation. 
Upon detection of RF signal, the repeater enables the Rx Audio lines and 
unmutes the speaker. 

In a Dynamic Mixed Mode repeater, the user is able to listen to the analog 
channel activity. However, for digital channel activity, the repeater will emit 
audible channel busy alert tone on speaker and Rx audio accessory pins, 
but it will not unmute to the actual digital channel activity. 


Repeater Knockdown 


Asserting this input pin triggers the repeater to temporarily enter Repeat 
Path Disable Mode. In this mode, the repeater’s transmitter will only be 
enabled by the external PTT and the audio source will be the Tx Audio 
Input pin. 

Releasing this input pin will revert the repeater back to Normal Mode 
where the repeaters transmitter can be activated by a qualified RF signal 
on the receive frequency. 

In Dynamic Mixed Mode, this feature is not supported during an ongoing 
digital transmission. 


Antenna Relay 


This output pin is used to drive an antenna relay switch for applications 
where the repeater acts as a dispatch station that will only receive or 
transmit at a time. This allows the use of a single antenna without the 
need of expensive combining equipment. The pin toggles active when the 
repeater enters a transmit state, and reverts to inactive when the repeater 
drops back to idle/receive. 

This feature is not supported in Digital and Dynamic Mixed modes. 
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2.20.5.1.3 Rear Accessory Port Fixed Audio Pins 

The following table provides a description of the fixed audio pins on the rear accessory connector 
for the XPR 8300/XPR 8380/XPR 8400 which can be used in Digital Telephone Patch or Analog 
modes only. 



Fixed Pins 


Description 


Spkr+/Spkr- 


Act as a differential pair and should be connected at opposite ends of an 
audio speaker or equivalent load. Under rated conditions, the output 
voltage will be 7.75V RMS and the radio supports impedances down to 4 
ohms with distortion typically less than 3%. Under no conditions should 
either of these two outputs be connected to ground. 


Rx Aud 


Provides a line level audio output at 330 mVrms under rated conditions. 
The frequency response of this output has been extended below 300 Hz 
to support data transfer for specific applications (Flat Unsquelch). 


Tx Aud 


Accepts transmit audio at 80 mVrms through a 560 Q load. Care must be 
taken when choosing an audio source as the output impedance of the 
source can affect the audio level which may need to be adjusted 
accordingly. 



The following table provides a description of the fixed audio pins on the rear panel ports for the 
MTR3000 which can be used in Digital Telephone Patch or Analog modes only. 



Fixed Pins 


Description 


Rx Audio 


An RF input signal with 60% RSD provides an Rx Audio output of 330 
mVrms into 50 kQ. Also a microphone input of 56 mVrms provides an Rx 
Audio output of 330 mVrms into 50 kQ. The Rx Audio output has DC bias 
of 2.5 VDC. 


Aux Rx Audio 


An RF input signal with 60% RSD provides an Aux Rx Audio output of 
330 mVrms into 50 kQ. The Aux Rx Audio output has a DC bias of 2.5 
VDC. 


Tx Audio 


The Tx Audio input provides no pre-emphasis. The nominal level of 80 
mVrms (226 mVpp) produces 60% Relative Standard Deviation (RSD). 


Tx Audio with Pre- 
Emphasis 


The Tx Audio-Pre input provides a pre-emphasis network. The nominal 
level of 80 mVrms (226 mVpp) produces 60% RSD. 


Tx Data 


Transmit data, PL or DPL signaling. The nominal level of 80 mVrms (226 
mVpp) produces 12% RSD. 
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2.20.5.1.4 Front Panel Audio Ports on the MTR3000 



The following table provides a description of the front panel ports for the MTR3000. 



Front Panel Ports 


Description 


Speaker 


Output to Powered Voice speaker. Adjustable between 0 to 500 mVrms 
[1.4 Vpp] across 2.4 kQ @ 60% system deviation. Audio signal appears 
between Pins 3 and 4 on the connector. Must use speaker type HSN1000 
(older model) or HSN1006 via adapter cable Part.No. 0185180U01 . 

NOTE: The Speaker port is only supported in analog mode regardless of 
the speaker used. 


Microphone 


Local microphone Input. Use microphone type GMN6147 (older model) or 
GMMN4063. Modulation sensitivity for 60% system deviation is typically 
56 mVrms (158 mVpp). 

NOTE: The Mic port is only supported in analog mode regardless of the 
Mic used. For older model of microphone (GMN6147), the 3 control 
buttons for speaker volume control, Rx monitor and Intercom control 
functions are not supported. 



2.20.5.2 Configuration Summary Table 

The following table gives a high level view of which features of the analog repeater interface are 
needed to support specific types of accessories. This table is meant to act only as a guideline. 



Acc Type 


Trunking 


Phone 

Patch 


Tone 

Panel 


Local 

Deskset 


Console 

Base 

Station 


RX Audio 


Y 


Y 


Y 


Y 


Y 


TX Audio (MTR3000) 


N 


Y 


N 


Y 


Y 


TX Audio (XPR 8300/ 
XPR 8380/XPR 8400) 


Y 


Y 


Y 


Y 


Y 


TX Audio with Pre- 
Emphasis (MTR3000) 


Y 


N 


Y 


N 


N 


TX Data (MTR3000) 


Y 


N 


Y 


N 


N 


Ext PTT 


Y 


Y 


Y 


Y 


Y 


Disable Repeat Path 


Y 


N 


Y 


N 


Y 


Repeater Knockdown 


NA 


Y 


NA 


Y 


NA 


Monitor 


N 


Y 


N 


Y 


Y 


PL Detect 


N 


O 


O 


O 


O 


CSQ Detect 


O 


O 


O 


O 


O 
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Acc Type 


Trunking 


Phone 

Patch 


Tone 

Panel 


Local 

Deskset 


Console 

Base 

Station 


Audio Type 


FLAT 


FILTERED 


FLAT 


FILTERED 


FILTERED 


Analog Accessory 
Emphasis 


NA 


O 


NA 


O 


O 


Antenna Relay 


NA 


NA 


NA 


O 


O 



Y = This feature is necessary for the application 
N = This feature is not necessary for the application 
O = This is an optional parameter for the application 
NA = Not Applicable 

2.20.5.3 Configuration Considerations 

2.20.5.3.1 Analog Trunking Controllers & Community Repeaters 

Most analog trunking controllers and community repeaters will have two outputs that are to be 
modulated by the repeater: voice audio, signaling data. The MOTOTRBO XPR 8300/XPR 8380/ 
XPR 8400 repeater only accepts one audio input. Thus the two outputs must first be mixed into a 
single input and dropped down to the audio level the MOTOTRBO repeater expects on the 
microphone port. 

The microphone port is designed to transmit audio at 80mV RMS (220 mVp-p) through a 560 ohm 
load. Care must be taken when choosing an audio source as the output impedance of the source 
can affect the audio level which may need to be adjusted accordingly. 

When mixing the audio and signaling, care must also be taken to determine the expected deviation 
of the signaling. For example, in LTR controllers, the expected deviation of the LTR data is 
~800Hz. Please refer to your controller’s user manual which gives guidance on how to tune the 
data signal output to achieve adequate data deviation. 

Similar to existing cables, resistors can be placed on the cable to drop the level coming out from 
the controller (on the order of 1-2 Vp-p) to the level expected by the transmit audio pin. Once the 
resistor value is determined, the audio and signaling signals can be mixed into a single wire that 
can be crimped onto the MOTOTRBO accessory connector (Motorola Part Number PMLN5072_). 

The MTR3000 repeater has an audio transmit input and a data transmit input that can be used 
with the two outputs on the analog trunking controllers and community repeater panels (tone 
panel). 
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2.20.5.3.2 Zetron Controllers 

The following are the Zetron configurations needed that will enable Zetron controllers to interface 
with the MOTOTRBO repeater. 



Zetron 



MOTOTRBO 



Pin 1 t 


<= 12VDC 




Pin 


Pin 3 


GND 




Pin 


Pin 7 1 


*PTT (N.O. Relay) => 


Pin 


Pin in 1 


< — i Squelch 




Pin 


Pin 11 1 


TX Audio 






Pin 12 t 


TX Audio GND 


3.3k 


Pin 


Pin 13 , 


LTR TX Data i=> 




Pin 14 1 - 


DISC. GND 


, 

3.3k 


Pin 


Pin IS . A 


<= DISC Audio 


12. 


Pin 



7 

8 
17 
22 

Pin 11 
12 



18 

14 



Figure 2-56 XPR 8300/XPR 8380/XPR 8400 Cable Schematic for Zetron Controllers 
Schematic Notes: 

• On the Zetron connector, pin 6 is PTT Common, this must be jumpered to one of the 
grounds. This is the common pin of the PTT relay. Without this, the unit will not key-up. 

• Use a shielded cable for Discriminator Audio. 

• The two 3.3k ohm resistors need to be mounted at the MOTOTRBO end of the cable. 

• Large arrows indicate signal/function flow. 

• Please note that Pin 17 (PTT) and Pin 22 (Squelch/CSQ Detect) need to be provisioned 
in the CPS. 

To set up the MTR3000 with Zetron controllers, see the MTR3000 Repeater Basic Service Manual 
(68007024096), Appendix D for more information. 

The following table lists the jumper/switch settings for trunking/tone panel controllers. 
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Zetron Model 42 Trunking Controller Jumper Settings 

JP1 set to ‘B’ (Flat) 

JP2 set to ‘A’ (Tone Flat) 

JP3 set to ‘A’ (Sub Out High) 

JP4 set to ‘A’ (+20dB Receive Audio Gain) 

JP6 set to ‘A’ (TX Audio Level High) 

JP7 set to ‘Ext Sq +’ (pins 5-7 and 6-8 jumpered) 

NOTE: If you have an older Zetron controller that will be used in a 12.5 kHz system for the 
first time, make sure it has first been modified for 12.5 kHz operation. See Zetron’s 
supplemental publication: 011-0509 for instructions on making this modification. 



Zetron Model 49 Trunking Controller Jumper Settings 

JP1 set to ‘A’ (Flat Audio) 

JP2 set to ‘A’ (Tone Flat) 

JP7 set to ‘A’ (COR as input) 

JP9 set to ‘A’ (+20dB Receive Audio Gain) 

JP10 set to ‘A’ (TX Audio Level High) 

JP12 set to ‘Ext Sq +’ (pins 5-7 and 6-8 jumpered) 

JP13 set to ‘B’ (HP Filter IN) 

JP23 set to ‘A’ (Sub In from Disc.: pins 1-2 and 3-4 jumpered (grounds pin 4 on rear 
connector)) 

JP24 set to ‘A’ (Sub Out DC coupling) 

JP25 set to ‘A’ (Sub Out High) 

JP26 set to ‘A’ (Sub Out analog) 

WARNING: Pin 4 of the rear connector is listed as a ground. But it will not be grounded 

unless JP23 is set for it. This pin also acts as an input for the receive LTR data 
path. See jumper table below. 

NOTE: The jumpers do not follow standard positioning. Some may be vertical, some may 
have position ‘A’ on the left, some may have position ‘B’ on the left. Take extra care 
when making these settings. 

NOTE: If you have an older Zetron controller that will be used in a 12.5 kHz system for the 
first time, make sure it has first been modified for 12.5 kHz operation. See Zetron’s 
supplemental publication: 011-0509 for instructions on making this modification. 

NOTE: For transmit audio alignment, the Zetron Model 49 manual calls for setting the Tone 
Generator at TP4 for 1 .4Vp-p/495mv RMS, then adjusting the TX audio for 2 kHz 
deviation (40% of full system deviation). This is for a 25 kHz BW system. For 12.5 
kHz BW, this adjustment is 1 kHz deviation. 
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Zetron Model 38 Tone Panel Switch Settings 

SW2 set to off (up) Audio Output Gain (high) 

SW3 set to off (up) PL/DPL output Gain (high) 

SW4 set to off (up) Flat/De-emphasis (Flat) 

SW6 set to off (up) Internal/External Squelch (External) 

SW7 set to on (Down) COR Positive/Negative (Negative) 



Tone Panel Programming Note: 

It may be necessary to set the generated DPL (DCS) signal to “Invert” from the tone panel to be 
recognized by the user radios. These DTMF commands are 3750 for normal and 3751 for inverted 
signal generation. 



Once the above cable and jumper/switch settings have been achieved, you should now be able to 
refer to the specific controller product manual to complete installation. 

2.20.5.3.3 Trident Controllers 

Trident Microsystems manufactures a cable that interfaces Trident Controllers with MOTOTRBO 
repeaters and provides jumper settings for Trident Controllers. 

2.20.6 Auto-Range Transponder System (ARTS) 

Auto-Range Transponder System is now available in analog mode (direct or repeater) in software 
version R02. 10.00. This feature informs radio users when their radio is out of range from other 
ARTS-equipped radios. 

ARTS uses automatic polling whereby the radio automatically transmits once every 25 or 55 
seconds in an attempt to “shake hands” with another ARTS-equipped radio. When a radio 
receives an incoming ARTS signal, a short in range tone sounds and an “In Range” message is 
shown on the radio. If a radio is out of range for more than two minutes, a short out of range tone 
sounds and an “Out of Range” message is shown on the radio. When radios return in range from 
out of range, a short in range tone sounds and an “In Range” message appears again on the radio 
to notify the user. 

The Auto-Range Transponder System (ARTS) feature has three operating modes: 

• Transmit Mode - The radio only transmits polling signals to connect with other radios. 
The radio does not receive signals and therefore does not notify the radio user of its own 
range status. 

• Receive Mode - The radio only receives polling signals to be notified when in range or 
out of range. The radio does not transmit polling signals to connect with other radios. 

• Transmit and Receive Mode - The radio transmits and receives polling signals. The 
radio can connect with other radios and notifies the radio user of its own range status. 

ARTS can only be active on analog channels with a TPL/DPL squelch type. A radio is considered 
to be in range if carrier and matching TPL/DPL is detected, regardless of which radio transmitted 
it. 

It is important to note that a radio with ARTS enabled only notifies the range status by receiving 
transmissions from other radios. This does not mean that the receiving radio can transmit or talk 
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back to the transmitting radio. A good example of this is when a mobile radio with high power 
transmits its ARTS polling signal to a portable radio with low power. Although the portable can 
receive the high power signal from the mobile and notify the radio user that it is in range, it may not 
be able to reach the mobile since it is transmitting using low power. 

Another very important item to note is that if there are many radios with ARTS enabled operating in 
Transmit and Receive (TRX) Mode in the same area, some of them may not be able to transmit 
successfully because of the excess loading on the channel. This should be considered when 
distributing radios across channels and when setting the ARTS TX Period. 

Because radios with ARTS enabled are required to transmit often, battery life may be impacted. 
This should be considered when setting the ARTS TX Period. 

The table below summarizes the programmable options for ARTS. 



Name 


Value 


Wide 


Description 


ARTS Mode 


Off/TX/ RX/TRX 


Channel 


ARTS operating mode 


ARTS TX Period 


25 / 55 (seconds) 


Channel 


ARTS TX period for polling 
transmission 


ARTS Audible Indication 


Off / Once / Always 


Radio 


Indicates whether radio sounds 
audible indications when valid 
transmission is received 


ARTS Visual Indication 


Off /On 


Radio 


Indicates whether radio shows 
visual indications 



2.20.7 TX Inhibit Quick Key Override 

This feature gives the radio user the ability to override the selected Busy Channel Lockout rule, 
thus allowing a transmission to be sent on a busy channel. The radio user accomplishes this by 
quick-keying the PTT button. This means pressing the PTT, then releasing, and quickly re- 
pressing within one second. This feature can be enabled or disabled via CPS. 

This feature is available for internal PTT, external PTT via accessory or Bluetooth, and XCMP PTT, 
but not applicable for VOX PTT via accessory or Bluetooth. This feature applies only when the 
radio is operating in analog conventional dispatch mode. This feature is only available in portables. 

2.20.8 Alert Tone Fixed Volume 

When the Alert Tone Fixed Volume feature is enabled via CPS, all alert tones remain at a constant 
volume level. This constant volume level is equal to the radio’s Midpoint Volume Setting, plus or 
minus the Alert Tone Volume Offset setting. The volume level for alert tones then remains 
constant, even when the radio’s volume knob is adjusted. 

This does not affect tone volumes that are automatically adjusted by the radio, for example, when 
Quik-Call II Call Alert, Escalate, and Intelligent Audio features are enabled. This feature is only 
available in portables, and both analog and digital modes. 
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2.20.9 Alert Tone Auto Reset 



The Call Alert tone is normally a repetitive alert tone. This feature enables the radio to generate 
only one sequence of the Call Alert tone when the radio decodes a Digital, MDC, or Quik-Call II 
Call Alert. The Call Alert tone duration can be configured via CPS from 0 (°°) second to 1200 
seconds by a five second increment. If the Infinity (°°) option is selected, the Call Alert tone 
continuously sounds until the user cancels the Call Alert indication. 

This is a radio-wide feature available in analog and digital modes. This feature is only applicable if 
the Disable All Tones feature is disabled. 

2.20.10 Emergency Permanent Sticky Revert 

This feature enables the radio to remain permanently on the Emergency Revert Personality after 
the emergency transmission has been sent and acknowledged. The radio must be powered off for 
it to return to the selected channel on the Channel Selector. 

Any mode change - analog vote scan, scan and auto scan will not work while the radio is 
operating on the Emergency Sticky Revert Channel. The radio can still receive MDC and Quik-Call 
II Call Alerts or Selective Calls, but cannot initiate them. 

This feature can be enabled or disabled via CPS and is only available in portable radios. 

Below is the table that summarizes the features supported by the MOTOTRBO Display Portable 
with XPR 6580/XPR7550 



Feature Name 


HT1250 


XPR 6580 


XPR 7550 


Talkaround/Repeater 
Mode Operation 


X 


X 


X 


12.5 kHz Configurable 
Bandwidth 


X 


X 


X 


PL/DPL Codes 


X 


X 


X 


Squelch 


X 


X 


X 


Monitor 


X 


X 


X 


Time-Out Timer 


X 


X 


X 


Channel Access Control 


X 


X 


X 


Option Board 
Expandability 


X 


X 


X 


Voice Announcement 






X 


Intelligent Audio 






X 


Built-in Bluetooth 






X 


Home Channel Revert 






X 
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Feature Name 


HT1250 


XPR 6580 


XPR 7550 


Continuous Rotary 
Channel Knob 






X 


Analog Signaling Features 


Quik-Call II 


Encode/Decode 


X 


X 


DTMF Encode/Decode 


Encode 


Encode (Live Dial Only) 


Encode (Live Dial Only) 


MDC-1200 Call Alert 


Encode/Decode 


Encode/Decode 


Encode/Decode 


MDC-1200 Selective 
Call 


Encode/Decode 






MDC-1200 PTT-ID 


Encode/Decode 


Encode/Decode 


Encode/Decode 


MDC-1200 Emergency 


Encode 


Encode/Decode 


Encode/Decode 


MDC-1200 Selective 
Radio Inhibit 


Decode 




Decode 


MDC-1200 Radio Check 


Encode/Decode 




Encode/Decode 


MDC-1200 Remote 
Monitor 






Encode/Decode 


Digital Signaling Features 


Call Alert 




Encode/Decode 


Encode/Decode 


Private Call 




Encode/Decode 


Encode/Decode 


PTT-ID 




Encode/Decode 


Encode/Decode 


Emergency 




Encode/Decode 


Encode/Decode 


Selective Radio Inhibit 




Encode/Decode 


Encode/Decode 


Radio Check 




Encode/Decode 


Encode/Decode 


Remote Monitor 




Encode/Decode 


Encode/Decode 


Analog Scan 


Scan 


X 


X 


X 


Nuisance Channel 
Delete 


X 


X 


X 


Priority Scan 


X 


X 


X 


Dual Priority Scan 


X 


X 


X 


Digital Scan 


Scan 




X 


X 
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Feature Name 


HT1250 


XPR 6580 


XPR 7550 


Nuisance Channel 
Delete 




X 


X 


Priority Scan 
(Talkaround) 




X 


X 


Priority Scan (Repeater 
Mode) 




X 


X 


Dual Priority Scan 
(Talkaround) 




X 


X 


Dual Priority Scan 
(Repeater Mode) 




X 


X 


Mixed Mode Scan 


Scan 




X 


X 


Nuisance Channel 
Delete 




X 


X 


Priority Scan 




X 


X 


Dual Priority Scan 




X 


X 
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SECTION 3 SYSTEM COMPONENTS AND 

TOPOLOGIES 

3.1 System Components 

MOTOTRBO consists of numerous components and applications that function together in a 
system. The first step in designing a system that satisfies the customer’s needs is identifying the 
devices and applications within the system, and then choosing a basic system configuration of 
how these components will be interconnected. This section defines the different components and 
applications available, their offered services, and their roles in the system. We will then describe 
some of the standard system topologies that MOTOTRBO supports. 

3.1.1 Fixed End Components 

The system contains devices with fixed locations and other devices that are mobile. This sub- 
section covers the devices with fixed locations. 

3. 1.1.1 Repeater 

The MOTOTRBO repeater provides an RF interface to the field subscribers. The repeater is AC 
and DC-powered and designed to be discreetly mounted on a standard 19” rack found in most 
communication tower locations. It offers front panel indicators of its current status including real 
time transmit and receive indicators for each time slot. Once configured through the Customer 
Programming Software (CPS), the repeater is designed to operate behind the scenes and without 
the need for further user interaction. 

The repeater can either be configured as a standalone repeater or as a repeater connected to a 
backend network, as in the case of IP Site Connect, Capacity Plus, and Linked Capacity Plus 
modes. As a repeater, it listens on one uplink frequency, and then re-transmits on a downlink 
frequency. Therefore a pair of RF frequencies is required for each repeater in the system. 

A major advantage of using a repeater in the system is that it allows a greater communication 
range than would be possible talking from subscriber to subscriber. Multiple repeaters can be 
installed in strategic locations for the users’ coverage to be consistent throughout their required 
range of operation. However, only in IP Site Connect mode, do the radios seamlessly roam 
between repeaters. In digital repeater mode, the users must know the coverage range provided by 
each repeater, and manually switch channels when necessary. 

The repeater is capable of operating in either digital mode, analog mode, or in Dynamic Mixed 
Mode. This is determined at the initial configuration, and is not updated dynamically. Therefore at 
any given time, it either operates as a digital repeater, as an analog repeater, or as a Dynamic 
Mixed Mode repeater. 

When configured for analog operation, the repeater is designed to operate with existing analog 
systems, therefore making migration to a MOTOTRBO system smoother. 

When configured for digital operation, the repeater offers additional services. The digital repeater 
operates in TDMA mode, which essentially divides one channel into two virtual channels using 
time slots; therefore the user capacity is doubled. The repeater utilizes embedded signaling to 
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inform the field radios of the busy/idle status of each channel (time slot), the type of traffic, and 
even the source and destination information. 

Another advantage during digital operation is error detection and correction. The further a 
transmission travels, the more predominant the interference becomes, and inevitably more errors 
are introduced. The receiving MOTOTRBO radio, operating in digital mode, utilizes built-in error 
detection and correction algorithms, native to the protocol, to correct these problems. The 
MOTOTRBO repeater uses the same algorithms to correct the errors prior to retransmission, thus 
repairing any errors that occur on the uplink; it then transmits the repaired signal on the downlink. 
This greatly increases the reliability and audio quality in the system, which increases the 
customer’s coverage area. 

In digital mode, the repeater only retransmits digital signals from radios configured with the same 
system identifier. This aids in preventing co-system interference. The repeater does not block 
transmissions of radios within its own system. 

As previously described, the repeater utilizes embedded signaling to announce the current status 
of each channel. It is up to the radios in the field to interpret these signals, and grant or deny their 
user’s request for transmission. Therefore, when a user or a group of users utilizes a channel (time 
slot), the repeater announces that the channel is being used and who is using it. Only radios that 
are part of that group are allowed to transmit. The repeater additionally allows a short duration of 
reserved time after a transmission. This allows other users in the group to respond to the 
originator. This reserved hang time greatly improves the continuity of calls, because new calls 
cannot start until the previous call ends. Without this feature, users may experience delays in 
responses (that is, between transmissions of calls), due to other calls taking over the channel in- 
between their transmissions. 

After this reserved hang time, the repeater continues to monitor for a short period. If no user 
transmits on the channel for a duration of time, the repeater stops transmitting. When the next 
radio transmission occurs, the repeater begins repeating again. 

In Dynamic Mixed Mode, the repeater dynamically switches between analog and digital calls. 
When a repeater repeats a new digital call that starts on one of the logical channels, the repeater 
does not qualify any analog call including an Emergency Call until the digital call (both the 
transmission and call hang time) is over and the corresponding channel hang time has expired. 
Upon the expiry of channel hang time, only then does the repeater start qualifying both analog and 
digital calls simultaneously. Similarly, if an analog call is being repeated, the repeater does not 
qualify any digital call including digital data and Emergency Calls on any of the two logical 
channels until the analog call is over and the corresponding hang time has expired. 

The repeater 4-wire interface and over-the-air digital calls are polite to each other. If the PTT 
button or knockdown GPIO pin is asserted on the repeater 4-wire interface while a digital 
transmission is ongoing, then an audible channel busy alert tone is generated on the speaker pin 
of the 4-wire interface. The PTT button press or pin knockdown operation is denied. 

In IP Site Connect, Capacity Plus, and Linked Capacity Plus modes, the repeaters perform the 
following additional duties: 

• Each repeater ensures that their communication links with other repeaters are open all the 
time. 

• They inform their operating status (e.g. mode, IPv4/UDP address) to each other. In Capacity 
Plus and Linked Capacity Plus, repeaters also inform the status of their logical channels to 
each other. Based on these status, a repeater selects the next Rest Channel. 
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• In IP Site Connect and Linked Capacity Plus modes, repeaters ensure that in cases of 
multiple calls starting within a short period, only one call per destination prevails at all the 
associated sites and all of them (except those that detect interference) repeat the selected 
call. 

• They inform their alarm conditions and provide diagnostic information to the RDAC-IP 
application. The RDAC-IP application allows its user to remotely change the mode of a 
repeater. 

3. 1 . 1 .2 MTR3000 Base Station/Repeater 

The MOTOTRBO MTR3000 base station/repeater provides a modular, flexible analog and digital 
station designed for today’s communication systems and for the future. 

The MTR3000 is an integrated data and voice base station/repeater designed to deliver increased 
capacity, spectral efficiency, integrated data applications and enhanced voice communications. 
The base stations are available for use in the following configurations: 

• Analog Conventional 

• Digital (MOTOTRBO) 

• MOTOTRBO DMR Tier 2 Conventional - Single Site 

• MOTOTRBO DMR Tier 2 Conventional - IP Site Connect 

• MOTOTRBO Capacity Plus Trunking 

• MOTOTRBO Linked Capacity Plus Trunking 

• MOTOTRBO Connect Plus Trunking 

• MOTOTRBO Transmit Interrupt 

• MOTOTRBO Dynamic Mixed Mode (DMM) 

• MOTOTRBO Enhanced GPS 

• LTR Trunking 

• Passport Trunking 

3. 1 . 1 .2. 1 MTR3000 Key Features 

The following are key features for the UHF and 800/900 MHz release: 

1. Wireline Card (supports integrated Tone Remote and DC Remote Control) 

2. Analog RSSI 

3. Hear clear (800/900 MHz only) 

4. MTR2000 MOTOTRBO Digital Upgrades for low and high power stations 

3. 1.1. 2. 2 MTR3000 Standard Features 

• Operates in analog or MOTOTRBO digital mode with a LED indicating mode of operation 

• Migration path from analog to digital mode 

• 12.5 or 25 kHz programmable channel spacing 

• Operation down to 8 W 
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• Reliable 100 W Continuous Duty Cycle Operation 

• Analog and digital conventional are all standard in one base station without the cost of 
additional software or hardware 

• Restriction of Hazardous Substances (RoHS) compliant 

• Switching power supply functions over a wide range of voltages and frequencies 



3. 1.1. 2. 3 MTR3000 Programmed in MOTOTRBO Mode 



• Supports two simultaneous voice paths in digital 12.5 kHz TDMA 

• Divides an existing channel into two timeslots delivering twice the capacity through a single 
repeater 

• Supports MOTOTRBO IP Site Connect for increased wide area coverage 

• Supports MOTOTRBO Capacity Plus Single Site Trunking without a separate hardware 
controller 

• Supports MOTOTRBO Linked Capacity Plus Multi Site Trunking without a separate 
hardware controller 

• Supports MOTOTRBO Dynamic Mixed Mode to facilitate your analog-to-digital migration in 
conventional repeater applications 

• Supports MOTOTRBO Transmit Interrupt for greater subscriber unit control and flexibility 



3. 1.1. 2.4 MTR3000 Serviceability 



• Repeater diagnostic and control software provides remote or local site monitoring 

• Easy to replace components with functionally separate Field Replaceable Units (FRU) 

• Software-based design simplifies feature upgrades 

• Easy access to station ports (no need to remove the front panel) shortening installation and 
maintenance time 

• For ease of installation, minimal station alignment is needed 

• Supported by Motorola’s 2-year standard warranty 



3. 1.1. 2. 5 Total Cost of Ownership 



• Analog Conventional, Digital Conventional are standard in one base station without the cost 
of additional software 

• Twice the spectral efficiency; one frequency pair provides two logical voice paths 

• Effectively twice the power efficiency as compared to two analog stations when operating in 
digital mode 

• Integrated Components optimizes expensive site space; one physical station provides the 
capacity of two in digital mode 
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3. 1.1. 2. 6 Wireline Interface Board 

The MTR3000 Wireline board is used to connect an analog audio source and sink (such as a 
console) to the MTR3000 Base Station/Repeater. The Wireline board supports Tone and DC. 

Remote Control modes that allow for channel selection and PTT signaling from compatible 
consoles. Local PTT operation is also supported. The Wireline can be configured for either 2-wire 
or 4-wire operation as needed. 

The table below provides a description of the impedance supported by the Wireline board. 



Option 


Functionality 


High Impedance 


For use with an external impedance matching 


600 Q 


For Argentina, Canada, Chile, Columbia, Ecuador, El Salvador, Guam, 
Hong Kong, India, Indonesia, Japan, Jordan, Kazakhstan, Kuwait, 
Macao, Malaysia, Mexico, Oman, Pakistan, Peru, Philippines, Russia, 
Saudi Arabia, Singapore, South Korea, Taiwan, Thailand, UAE, USA 
and Yemen 


270 Q + (150 nF || 750 Q) 


For Austria, Belgium, Denmark, Finland, France, Germany, Greece, 
Iceland, Ireland, Italy, Luxembourg, Netherlands, Norway, Portugal, 
Spain, Sweden, Switzerland, Bahrain, Croatia, Cyprus, Czech 
Republic, Egypt, Hungary, Israel, Latvia, Lebanon, Malta, Morocco, 
Nigeria, Poland, Romania, Slovakia and Slovenia 


220 Q + (115 nF || 820 Q) 


For Australia, Bulgaria and South Africa 


370 Q + (310 nF || 620 Q) 


For New Zealand 


900 Q 


For Brazil 


320 Q + (230 nF || 1050 Q) 


For United Kingdom 


200 Q + (100 nF || 680 Q) 


For China 


900 Q || 30 nF 


For legacy MTR2000 
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3. 1.1. 2. 7 Repeater Specifications 

The MOTOTRBO repeater is currently available in 12.5 kHz operation in analog, or 12.5 kHz in 
digital. The table below shows the available repeater bands and associated power levels that are 
currently supported. 



Repeater Type 


XPR 8300/XPR 8380/XPR 8400 


Dimensions 
(h x 1 x w) 


5.25“ xl 1.75” x19" 

(133.35mm x 298.45mm x 482.59mm) 


Weight 


14 kg (31 lbs) 


Power 

(watts) 


UHF 1 


1 -25 


25-40 


UHF 2 


1 -40 


- 


VHF 


1 -25 


25-45 


350 MHz 


— 


800 MHz 


1 -30 



Repeater Type 


MTR3000 


Dimensions 
(h x 1 x w) 


5.25"x16.5”x19” 

(133.35mm x 419.09mm x 482.59mm) 


Weight 


19 kg (42 lbs) 


Power 


UHF 1/UHF2 


800/900 MHz 


VHF 


8 - 100 W 


8- 100 W 


8- 100 W 



3. 1 . 1 .3 MTR3000 Satellite Receiver 

The MTR3000 Satellite Receiver - provides a modular, flexible analog and digital station 
designed for today's communication systems and for the future. It is designed to eliminate “dead 
zones” in a communications system by improving the “talk-in” coverage on a particular receive 
frequency when used in a receiver voting system. 

Like the Base Station/Repeater, the Satellite Receiver is divided into functional modules that 
separate the frequency band specific functions (e.g. RF receive) from that of non-frequency 
specific functions (e.g. station control, user audio and GPIO interface, power system, etc.) 

These modules are self-contained functional blocks with module-specific alarms. This design 
facilitates the field replaceable unit (FRU) concept of field repair to maximize system uptime. 

The satellite receiver (T7713A) contains the following: 



Receiver Module 
Station Control Module 
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• Power Supply Module 

• Backplane Board 

• Wireline Board (standard) 

NOTE:The MTR3000 Satellite Receiver does not contain a transmitter, however, the RDAC 
application is supported in local and remote network connections. 

3. 1 . 1 .3. 1 Satellite Receiver System 

Typically, the satellite receiver connects to a Spectra-TAC™ or a DigiTAC™ comparator. 

Figure 3-1 shows a typical voting system and the connections of the satellite receivers. 




Satellite Receiver 



Figure 3-1 Satellite Receiver Connections Within a Voting System 
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3. 1 . 1 .4 Satellite Receiver and Voting Repeater 

A satellite receiver is required when digital voting is enabled in the system. The satellite receiver is 
a RF receiver-only device used to extend the repeaters’ inbound range. The device functions to 
receive over-the-air transmission from the radios, forwards the transmission over an IP link to the 
voting repeater. The voting repeater then “votes” on all the transmissions received from all its 
receivers, including its internal receiver and all its satellite receivers, based on the quality of the 
bursts. The voted result is then repeated over the air, and other sites or applications. 

The satellite receivers reuse repeater hardware; the following repeaters may be used as satellite 
receivers: 

• MOTOTRBO 32 MB Repeaters (MTR3000 and XPR Series) 

• MTR3000 Receiver only boxes 

The regular receive-and-transmit repeater with a built-in voting capability is usually called a voting 
repeater. Therefore there is no additional voting device in the system. The voting process is a 
software module built inside the voting repeater. The following repeaters can be used as voting 
repeaters: 

• MOTOTRBO 32 MB Repeaters (MTR3000 and XPR Series) 
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3.1 .1 .5 Radio Control Station 

The MOTOTRBO Control Station is based on the MOTOTRBO Mobile, except that it is configured 
to be the RF link from the data Application Server to the repeater and other radios. It is integrated 
with an AC power supply and appropriate housing to be placed on a desk. Since it is the radio 
gateway to the server, it is configured to transmit and receive on a single channel. It is 
programmed with a known radio ID, so that field radios know how to contact the server. In a 
MOTOTRBO system, there can be up to 16 control stations connected via four USB ports; each 
control station communicates through a separate logical channel, that is a TDMA slot. 

In most cases, the Control Station is externally controlled by the PC. It requires no user interaction 
once programmed. However, if a situation requires the use of a control station to transmit voice, it 
is capable of transmitting voice as well. 

Capacity Plus or Linked Capacity Plus configurations with Data Revert Channels requires a set of 
control stations to route data from radios to the Server and another set of control stations to route 
data from the Server to radios. Control stations operating in conventional mode (called Revert 
Control Stations) are used for routing data messages from radios to a data Application Server. 
Alternatively, control stations operating in Capacity Plus or Linked Capacity Plus modes (called 
Trunked Control Stations) are used for routing data messages from the data Application Server to 
the radios. Unlike Revert Control Stations, idle Trunked Control Stations move with the Rest 
Channel and therefore are on the same channel with all the idle radios. See “Capacity Plus 
Devices with Data over Trunked Channels” on page 263. 

3.1 .1 .6 MOTOTRBO Network Interface Service (MNIS) 

The MOTOTRBO Network Interface Service (MNIS) is a Windows service application which 
supports data applications such as Text Messaging, Location, Telemetry, and others, without 
requiring control stations. It connects with the repeater system over an IP network and utilizes the 
repeaters to transmit and receive data messages between data applications and MOTOTRBO 
radios. Voice and CSBK calls are currently not supported. 




MOTOTRBO Network Interface Service 
MOTOTRBO Device Discover and Mobility Service 
Data Application - Text, Location, Telemetry, ... 



□ 



□ 






Digital Radio 



Repeater System 

Single Site Conventional, IP Site Connect or 
Capacity Plus, or 
Linked Capacity Plus 



Figure 3-2 MOTOTRBO Network Interface Service (MNIS) 



The following system configurations are supported by the MNIS: 



• Single Site Conventional Digital 

• IPSC Conventional 

• Capacity Plus 

• Linked Capacity Plus 
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Data Revert Channels and Enhanced GPS Revert Channels are supported. Data on voice 
channels are supported too, however, only on selected conventional channels or Trunked 
Channels. In IPSC, both wide and local area channel configurations are also supported. 

The following MOTOTRBO data features are supported by MNIS: 

• Layer 2 confirmed and unconfirmed data message delivery 

• Individual and Group data messages 

• Basic and Enhanced Privacy 

• Data message IP/UDP header compression 

• Data Precedence and Data Over Voice Interrupt access priority 

The MNIS supports MOTOTRBO data applications, including Text Messaging, Location, 
Telemetry, Third-Party Raw Data, and OTAP with CPS. The MNIS requires the MOTOTRBO 
Device Discovery and Mobility Service application (DDMS), formerly called the MOTOTRBO 
Presence Notifier, for radio ARS. 

There are several benefits of selecting MNIS over control stations, particularly when the control 
stations are used only by data applications. Some of the benefits include: 

• The deployment is simpler compared to using control stations, because control stations and 
other associated hardware such as power supplies, antennae, and others are not required. 

• Previously, data revert channels were required to be wide area in order for the data 
messages to be routed to the site where the control stations are located. Now, MNIS allows 
a centralized data application to access local Data Revert Channels at all remote sites. The 
former wide area Data Revert Channel can now be split into multiple local Data Revert 
Channels, which routes data to the centralized data application via MNIS, thus allowing 
higher data throughput from each remote site. 

• MNIS connectivity with the system can be monitored via RDAC. 

However, there are a few considerations to take note of: 

• The MNIS does not support Dynamic Mixed Mode system configuration. 

• The repeater’s “Network Application Interface for Data” feature must be enabled to allow the 
MNIS to interface with the repeater. 

• The MNIS does not support L2 fragmented data. Ensure that the largest data size [Data 
Message + IP/UDP Header] transmitted from the radio is less than the Max TX PDU Size 
configured in the radios. 

• The MNIS software is available on the MOTOTRBO MOL website. 
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3.1. 1.7 MC1000, MC2000, MC2500 Console 

The MOTOTRBO mobile supports the MC Deskset Series of consoles. The MC Deskset Series 
provides a complete portfolio of products for a small control room. Each unit provides control of the 
radio(s) via a compact desk unit offering a choice of control methods: Local and Remote. The 
portfolio ranges from a simple talk and listen unit to a miniature multi-channel console. 

The MCI 000 can control a single control station, and provides a selection of up to four 
frequencies. This unit requires no software for programming. 

The MC2000 can also control a single control station, but provides a selection of up to 16 
frequencies. Programming this unit is through configuration software installed on a PC. 

The MC2500 controls up to 4 control stations, with the ability to patch and multi-select channels. 
All channels are capable of 16 frequency controls. This unit is programmed through configuration 
software installed on a PC. 

Each unit ships with a power supply and manual. The MC1000 ships with a 110V, 60Hz unit, while 
the MC2000/MC2500 ship with an 110/220V, 50/60Hz unit. 

The MOTOTRBO mobile can be interfaced with the MCI 000, MC2000 and MC2500 Desktop 
Consoles. These consoles allow for remote and local access to the MOTOTRBO Control Station. 
The interface to the console uses a 26-pin MAP connector. The console interface to the control 
station consists of TX_Audio, RX_Audio, PTT, Monitor and Channel Activity. Additionally, channel 
steering is provided by the mobile radio through the GPIO pins, which are configurable using the 
CPS. Advanced MDC commands are only supported in analog mode and a not in digital mode. 

Please refer to the analog console installation manual for more details on analog console 
configurations. 
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3.1.2 Mobile Components 

Most users of the MOTOTRBO system will be utilizing mobile devices (non-fixed) to access the 
system. Below are the devices currently available in the following frequency ranges and power 
levels. 

The MOTOTRBO portable is currently available in the following frequency ranges and power 
levels: 



Freq. Band 


Frequency Range 


Power Level 


UHF 1 


403-470 MHz 


1-4 Watts 


UHF 2 


450-512 MHz 


1-4 Watts 


VHF 


136-174 MHz 


1-5 Watts 


800 MHz 


806 - 824 MHz 
851 -869 MHz 


1-2.5 Watts 


900 MHz 


896 - 902 MHz 
935-941 MHz 


1-2.5 Watts 



The MOTOTRBO mobile is currently available in the following frequency ranges and power levels: 



Freq. Band 


Frequency Range 


Power Level 


UHF 1 


403-470 MHz 


1 - 25 Watts 
25 - 40 Watts 


UHF 2 


450-512 MHz 


1-40 Watts 


VHF 


136- 174 MHz 


1 - 25 Watts 
25 - 45 Watts 


800 MHz 


806 - 824 MHz 
851 -869 MHz 


1 - 35 Watts 


900 MHz 


896 - 902 MHz 
901 -902 MHz 
935-941 MHz 
940 - 941 MHz 


1 - 7 Watts 
1-30 Watts 
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3. 1.2.1 MOTOTRBO Portable 

The MOTOTRBO portable is a durable, but lightweight radio that offers many ways to access the 
system’s features. It is designed to allow users to take it with them anywhere, and yet remain 
connected to the system. 

The following table lists the average battery life for conventional operation at 5/5/90 duty cycle with 
battery saver enabled, GPS options disabled, no option board, no attached accessories, 
performing with carrier squelch for analog mode, ETSI DMR Tier 2 standard for digital mode, and 
transmitting at high power. Actual performance may vary by band and usage characteristics. 



Battery Type 


Battery Life 


NiMH 1300 mAh Battery 


Analog: 8 Hours 
Digital: 11.2 Hours 


IMPRES FM Li-ion 1400 mAh 
Battery 


Analog: 8.7 Hours 
Digital: 12.1 Hours 


IMPRES Li-ion 1500 mAh Slim 
Battery 


Analog: 9.3 Hours 
Digital: 13 Hours 


IMPRES Li-ion 2200 mAh 
Battery 


Analog: 13.5 Hours 
Digital: 19 Hours 



The portable is available in two tiers: 

• A keypad radio with display, and 

• A non-keypad radio with no display. 

The portable is fully configurable via the Windows-based CPS. It can be programmed to allow 
access to all MOTOTRBO features and all channels within the system or can be simplified to only 
allow limited access. The MOTOTRBO portable can truly be configured to cater to your customer’s 
needs. 
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3. 1.2. 1.1 User Interface 




Figure 3-4 MOTOTRBO Portable (Non-Display Model) 
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The primary buttons of the MOTOTRBO portable offer the user the ability to initiate most system 
features. These buttons and switches should be very familiar to radio users. 

Push-to-Talk Button 

The large round Push-To-Talk button, or PTT button, is the primary button used to initiate voice 
transmissions. Its location is on the left side of the portable, but is still easy to reach for both right- 
handed or left-handed users. The button is raised from the side and has a raised pattern, so that it 
is easily found even under low light conditions. Pressing the PTT button starts a voice 
transmission on the selected channel. This enables the user to simply push and talk. 

Channel Selector Knob 

The MOTOTRBO portable user chooses his communication environment by twisting the 16 
position channel knob on the top of the portable radio. This Channel Selector Knob is the main 
way a user uses to access the system. It also has a raised pattern, so it too is easy to find under 
low light conditions. Although easy to find, it is designed to require some force to turn it, so as not 
to be accidentally rotated through normal user activities. Each knob position can be programmed 
to access a different channel within the radio’s programming. This allows the user to quickly switch 
between analog and digital channels and even different groups. 

But the user is not limited to 16 channels. He can place up to 16 channels into a zone, and then 
switch between multiple zones. This greatly increases the number of available channels to the 
user. 

Programmable Buttons 

There are programmable buttons on the MOTOTRBO portable. The display portable has 6 
programmable buttons, while the non-display portable only has 4 programmable buttons. Each 
button can be programmed to perform a particular function. The short press and long press can be 
programmed to act differently. The orange button located on the top of the radio is commonly used 
to initiate emergency alarms, although it can be configured to function differently. 

Status Indicators 

There are a few different ways to provide feedback to the user. Depending on its color and state, a 
large tri-colored LED on the top of the radio indicates whether the radio is transmitting or receiving, 
and whether the selected channel is busy or idle. The LED busy indication represents the 
presence of RF activity on the selected channel and is not specific to the digital slot currently being 
monitored. The MOTOTRBO keypad portable with display also has a two-line LCD that displays a 
wide variety of information including received signal strength, battery power, emergency status, 
received text message indicator, monitor on/off, and GPS status. This display also allows each 
channel name to be displayed, so that the user knows the name of the selected channel. The 
source ID and target group alias are also displayed. User names are kept in an address book. This 
allows the user to assign user-friendly names as aliases to a radio ID. Various alert tones, talk 
permit tones and keypad tones are also available to give additional audio feedback to the user. 

Menu System 

In addition to accessing system features via buttons, the MOTOTRBO keypad portable with 
display offers a menu shown on its two line LCD display. With use of a menu button, left and right 
arrow buttons, a back/home button, and an OK button for selection, users can easily navigate 
through the following additional features. 
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• Contacts 

• Scan 

• Messages 

• Call Logs 

• Utilities 

For further details on these menus, please see the MOTOTRBO portable user manual. 

Full Keypad 

The MOTOTRBO keypad portable with display offers a full numeric keypad for users to manually 
enter target addresses for system features. This keypad is also used as an alphanumeric 
keyboard for text messaging. The non-display portable does not come with a keypad. 

3. 1.2. 1.2 Voice Feature Support 

With use of the MOTOTRBO portable interface, the user has access to all the voice features the 
MOTOTRBO system as to offer. These features include Group Calls, Private Calls, All Calls, and 
Emergency Calls. 

3. 1.2. 1.3 Command and Control Feature Support 

Command and control system features like Radio Check, Call Alert, Remote Monitor, Radio 
Enable/Disable are all accessible from the MOTOTRBO portable’s user interface. 

3. 1.2. 1.4 Analog Compatibility 

The radios can be programmed to support many current analog system features. Supported 
analog features include: 

• Analog communications on a 12.5 kHz channel (as standard), 

• Private-Line (PL) and Digital Private-Line (DPL) coded squelch control (as standard), 

• MDC signaling. 

3. 1.2. 1.5 Integrated GPS Antenna and Receiver 

The MOTOTRBO portable can contain an internal GPS receiver that works with the Location 
Services / Tracking Data Application. The location application and radio can be configured so that 
the radio transmits its location to a centralized application. The GPS antenna is integrated into the 
portable’s main antenna. In the LCD display on the radio, an icon indicates if the radio is in range 
of the GPS satellites. 
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3. 1.2. 1.6 Text Messaging Compatibility 

The MOTOTRBO portable can receive and transmit text messages. These can be Quick Text (pre- 
defined) messages already stored on the portable. In the case of keypad radio with display, 
freeform messages also can be created using the keypad. Through the menu, the user can access 
the Inbox that contains all the messages he has received. The radio allows a user to send a text 
message to an individual, a dispatcher or a group of radios. He can also reply to and forward text 
messages to other radios. 

Do note that all the features mentioned apply to the radio’s built-in text messaging as well as to 
“mobile on a PC” text messaging. 

3. 1.2. 1.7 Accessory and Peripherals Interface 

The MOTOTRBO portable radio supports an improved accessory and peripherals interface. This 
new interface is Motorola’s platform for future accessory development, and is not compatible with 
older accessories. It supports the following capabilities: 

• Enhanced Audio Functionality - This unique technology enables communication between 
the radio and Motorola’s enhanced accessories to optimize audio performance. It enables 
more consistent audio levels between accessory types. So headsets, remote speaker mics, 
or the radio’s built-in mic and speaker sound more consistent and interoperate more 
effectively. It also optimizes audio quality performance for a given accessory type, by 
employing digital signal processing (DSP) technology to best match the radio’s audio signals 
to the capabilities of the accessory. 

• USB Capability - The MOTOTRBO accessory and peripherals interface incorporates the 
standard Universal Serial Bus (USB) capability, thus enabling IP connectivity via standard 
USB ports with personal computers and other peripherals via a Motorola-supplied cable. 
This interface supports radio programming capabilities with no Radio-Interface-Box (RIB) 
required. It also enables the interface to MOTOTRBO data applications such as text 
messaging and location tracking. This interface also supports third-party applications by 
enabling interfaces for IP data service, telemetry services, text messaging and location 
tracking. 

• Core peripheral - The MOTOTRBO accessory and peripherals interface also includes core 
functionality for audio input and output, PTT, monitor, receive unsquelch, channel steering, 
and other general purpose input-output (GPIO) functions. This enables interface with 
dispatch and telemetry applications and other traditional radio system applications. 

• RF input/output - The MOTOTRBO accessory and peripherals interface also includes 
antenna signal (RF input/out) for use with future accessories such as public safety style 
microphones and vehicular adaptors. 

• Rugged and Submersible - The MOTOTRBO accessory and peripherals interface meets 
IP57 requirements (submersible to 1 meter for 30 minutes), thus enabling development of 
rugged and submersible accessories. 
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3.1. 2.2 MOTOTRBO Mobile 

The MOTOTRBO Mobile is designed to be located in a vehicle and powered by the vehicle’s 
battery or by AC power. Its durable construction makes it safe to use in most in-vehicle 
environments. It also can be used on desktops that are not truly mobile. Similar to the portable, the 
mobile offers numerous ways to access the system’s features. 

The mobile is available in two tiers: 

• A radio with full display, and 

• A radio with numeric display. 

The mobile is fully configurable via the Windows-based configuration software (CPS). It can be 
programmed to allow access to all MOTOTRBO features and all channels within the system, or 
can be simplified to only allow limited access. The MOTOTRBO Mobile can truly be configured to 
cater to your customer’s needs. 
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3. 1.2. 2.1 User Interface 




Power Button Numeric Display 




Figure 3-6 MOTOTRBO Mobile Control Head (Numeric Display Model) 

The primary buttons of the MOTOTRBO Mobile offer the user the ability to initiate most system 
features. These buttons and switches are the corner stone of the radio and should be very familiar 
to radio users. 
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Push-to-Talk Button 

The Push-To-Talk (PTT) button on the microphone is the primary button used to initiate voice 
transmissions. The cable connecting the microphone to the mobile is long enough to be 
comfortably used by either a right handed or left handed user. The button is raised from the side 
and has a raised pattern so that it is easily found in the low light conditions. Pressing the PTT 
starts a voice transmission on the selected channel. This enables the user to simply Push and 
Talk. The MOTOTRBO mobile can also interface to other accessories such as a Visor Microphone, 
a Foot Switch and an enhanced full keypad microphone. Motorola Original™ accessories provide 
an easy way to turn the MOTOTRBO mobile radio into a custom communication solution to fit your 
business requirements. 

Channel Rocker 

The MOTOTRBO Mobile user chooses his communication environment by selecting a channel 
using the Channel Rocker on the control head. The Channel Rocker has a raised pattern that is 
backlit so it is easy to find in low light conditions. Although easy to find, it requires some force to 
push it so as not to change channels through accidentally pressing. Each press can be 
programmed to access a different channel within the radio’s programming. This allows the user to 
quickly switch between analog and digital channels and even different groups. The user can 
quickly switch to different channels by pushing the up or down sections of the rocker. This greatly 
increases the number of available channels to the user. 

Programmable Buttons 

There are programmable buttons on the MOTOTRBO mobile. The full display mobile has four 
programmable buttons while the numeric display mobile has two programmable buttons. Each 
button can be programmed to perform a particular function. The short press and long press can be 
programmed to act differently. The buttons can be programmed to give quick and easy access to 
the MOTOTRBO system features, triggering emergency alarms and operating horns or lights. 

Status Indicators 

The MOTOTRBO mobile provides a multi-colored LED on the front of the radio that informs the 
user of the busy or idle status of the selected channel. The LED busy indication represents the 
presence of RF activity on the selected channel and is not specific to the digital slot currently being 
monitored. The MOTOTRBO Mobile also provides a two line LCD display that shows a wide 
variety of information, including received signal strength, battery power, emergency status, monitor 
on/off, and GPS status. This display allows each channel name to be displayed so that the user 
knows the name of the selected channel. The source ID and target group alias are also displayed 
for ease of use. User names are kept in an address book. This allows the user to use familiar 
names as aliases a radio ID. Various audio alert tones, talk permit tones and keypad tones are 
available to help the user navigate. 

Menu System 

In addition to the accessing system features via buttons, the MOTOTRBO Mobile offers a menu 
shown on its two line LCD display. With use of a menu button, left and right arrow buttons, a back / 
home button, and an OK button for selection, users can easily navigate through the following 
additional features. The Menu includes: 

• Contacts 

• Scan 
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• Messages 

• Call Logs 

• Utilities 

For further details on these menus, please see the MOTOTRBO mobile user manual. 

Full Keypad 

As an option, the MOTOTRBO Mobile offers an Enhanced Keypad Microphone so that users can 
manually enter target addresses for system features. Text messaging from the mobile will be 
available to the end user if the MOTOTRBO mobile is configured with an Enhanced Keypad 
Microphone. The Enhanced Keypad Microphone has a keypad that also doubles as a keyboard for 
text messaging. 

3. 1.2. 2. 2 Voice Feature Support 

With use of the MOTOTRBO Mobile interface, the user has access to all the voice features the 
MOTOTRBO system as to offer. These features include: Group Calls, Private Calls, All Calls, and 
Emergency Calls. 

3. 1.2. 2. 3 Command and Control Feature Support 

Command and control system features like Radio Check, Call Alert, Remote Monitor, and Radio 
Enable/Disable are all accessible from the MOTOTRBO Mobile’s user interface. 

3. 1.2. 2.4 Analog Compatibility 

The radios can be programmed to be backwards compatible and can support many current analog 
system features. These analog channels can be accessed through the Channel Rocker. 
Supported analog features include: 

• Analog communications on a 12.5 kHz channel 

• Private-Line (PL) and Digital Private-Line (DPL) coded squelch control 

• MDC signaling (Emergency, PTT ID and Call Alert) 

3. 1.2. 2. 5 Integrated GPS Antenna and Receiver 

The MOTOTRBO Mobile can also be purchased to contain an internal GPS receiver that works 
with the Location services / tracking data application. The location application and radio can be 
configured so that the radio will transmit its location to a centralized application. The GPS antenna 
is an external antenna that will have to be mounted on the vehicle. In the LCD display on the radio, 
an icon will display whether or not the radio is in range of satellites. 

3. 1.2. 2. 6 Text Messaging 

The MOTOTRBO Mobile can receive and transmit text messages. Through the menu, the user 
can access an inbox that contains all the messages he has received. When composing a 
message, the user can generate a free form text message or choose from a list of Quick Text (pre- 
defined) messages. The MOTOTRBO radio allows a user to send a text message to an individual, 
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a dispatcher or a group of radios. He can even reply to and forward text messages to other radios. 
If the MOTOTRBO mobile is not configured with the Enhanced Keypad Microphone, then text 
messaging can be accomplished through a mobile computer, running the text messaging client 
connected to the mobile. Using CPS, the radio can be configured to support text messaging 
internally or forward data to a mobile computer connected to the radio. 

Do note that all the features mentioned apply to the radio’s built-in text messaging as well as to 
“mobile on a PC” text messaging. 

3. 1.2. 2. 7 Front Panel Accessory Interface 



The MOTOTRBO mobile radio supports an improved front panel accessory interface. This new 
interface is Motorola’s platform for future accessory development and is not backwards compatible 
with older accessories. This interface supports the following capabilities: 



• Enhanced Audio Functionality - This unique technology enables communication between 
the radio and Motorola enhanced accessories to optimize audio performance. It enables 
more consistent audio levels between accessory types, so that users of different 
microphones will sound more consistent and interoperate more effectively. It also optimizes 
audio quality performance for a given accessory type, employing DSP (digital signal 
processing) technology to best match the radio’s audio signals to the capabilities of the 
accessory. 

• USB Capability - The MOTOTRBO accessory and peripherals interface incorporates 
standard Universal Serial Bus (USB) capability, enabling IP connectivity via standard USB 
ports with Personal Computers and other peripherals via a Motorola-supplied cable. This 
interface supports radio programming capabilities with no RIB box required, from the front 
(microphone port) connection. It also enables the interface to MOTOTRBO data applications 
such as text messaging and location tracking. This interface also supports third-party 
applications by enabling interfaces for IP data service, telemetry services, and text 
messaging and location tracking. 

• Improved Connection - The MOTOTRBO microphone connection employs a rugged “twist 
and lock” mechanism for greater durability and connection strength. 



3. 1.2. 2. 8 Rear Accessory and Peripherals Interface 



The MOTOTRBO mobile radio also supports an improved rear panel accessory and peripherals 
interface. It supports the following capabilities: 

• USB Capability - The MOTOTRBO accessory and peripherals interface incorporates 
standard Universal Serial Bus (USB) capability, enabling IP connectivity via standard USB 
ports with Personal Computers and other peripherals via a Motorola-supplied cable. This 
interface supports radio programming capabilities with no RIB box required. It also enables 
the interface to MOTOTRBO data applications such as text messaging and location 
tracking. This interface also supports third-party applications by enabling interfaces for IP 
data service, telemetry services, and text messaging and location tracking. 

• Core peripherals - The MOTOTRBO accessory and peripherals interface also includes core 
functionality for audio input and output, PTT, monitor, receive unsquelch, channel steering, 
and other general purpose input-output (GPIO) functions. This enables interface with 
dispatch and telemetry applications and other traditional radio system applications. 
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3. 1.2. 3 Application Server 

The Application Server is a computer that contains all the server-based software applications used 
on the MOTOTRBO system. It must meet the minimum hardware requirements for all the software 
applications installed on it. These applications typically are the Text Message Server and Client, 
the Location Server and Client, the Presence Notifier, and the Multi-Channel Device Driver (not 
required for the Capacity Plus/Linked Capacity Plus configurations and not with MNIS ). Details of 
these applications are discussed later in this chapter. 

Because the Server can be interfaced to a maximum of sixteen (16) control stations via USB, a 
hub with 16 USB ports is required. The Application Server should be in a centralized location, so 
the Control Stations (which are connected via USB) are within good RF coverage of all repeaters 
or direct mode/dual capacity direct mode radios. 

3.1 .2.4 MOTOTRBO Device Discovery and Mobility Service (DDMS) 

The MOTOTRBO Device Discovery and Mobility Service (DDMS) application replaces the 
MOTOTRBO Presence Notifier in software versions R02.06.10 and later. 

The application supports radios presence and radio mobility notification services. It can be 
deployed with the controls station or the MNIS. In deployments with a control station, the DDMS 
only supports radio presence notifications. In deployments with the MNIS, it supports presence as 
well as mobility notifications. 

3.1. 2.4.1 Presence Notification Service 

MOTOTRBO systems can support a number of different data applications. The various data 
applications often need to know the status of a particular radio within the system, prior to any 
communication attempt. As more applications are added to the MOTOTRBO system, in order to 
reduce complexity and be efficient in the use of the bandwidth, the radios are only required to 
register with the MOTOTRBO Device Discovery and Mobility Service (DDMS). 

The DDMS monitors the presence of Automatic Registration Service (ARS) capable radios, and 
reports their state to interested applications. These applications are also known as ‘Watchers’. The 
primary purpose of the DDMS is to provide the presence or absence of radios to the Watcher 
applications. 

Using CPS, the radio is programmed with the ARS Server (DDMS) IP address (in version 4 or IPv4 
format) and a UDP/IP port number. Upon power-up, the MOTOTRBO radio forms an ARS Device 
Registration message, and sends it to the DDMS. If the DDMS does not respond within a pre- 
defined interval, another ARS Device Registration message is sent to the server. This continues 
for a pre-defined number of retries. Since the radio expects a response to its ARS registration, the 
re-tries from the radios may cause unnecessary busy channels if the DDMS or an ARS Server is 
not present in the system. 

A Watcher is an application that requires information about the presence state of radios in the 
system. The Watcher is configured to ‘subscribe’ to the DDMS, and requests for information of a 
specific radio by its Device ID, IP address or User Name. The DDMS responds to a Subscribe 
request by sending back at least one Notify message containing the current presence state of the 
radio in question. As the state of the radio changes, the DDMS communicates the changes to all 
subscribing Watchers by generating the appropriate Notify messages. 
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3. 1.2.4. 2 Mobility Notification Service 

When DDMS is deployed with MNIS, both radio presence as well as mobility notification services 
are supported. The channel and site where a radio transmits its ARS Device Registration message 
provides the radio’s mobility information, which gets recorded in the DDMS. The MNIS subscribes 
with the DDMS to receive the radio’s mobility information, and uses it to route the application data 
to the radio. Besides MNIS, other watcher applications can also subscribe with DDMS to receive 
radios’ mobility information. The DDMS watcher interface is extended for radio mobility service 
subscription and notification. 

NOTE:The DDMS is fully backward compatible with the MOTOTRBO Presence Notifier 
application. Existing applications that interface with the Presence Notifier do not require 
any changes to receive presence notifications. In the System Planner, the DDMS is 
assumed where ever the Presence Notifier is mentioned. 

3.1 .2.4.3 DDMS Computer Specifications 



Component 


Requirements 


Operating Systems 


Windows 7 Home Premium Edition (32 & 64-bit) 


Windows 7 Professional Edition (32 & 64-bit) 


Windows XP Home/Professional Edition with SP3 & Windows Installer 
3.1 (32-bit) 


Windows Server 2003 (32 & 64-bit) 


Windows Server 2008 R2 (64-bit) 


Memory 


DDMS: 1 GB and above required by host Operation System 


Hard Disk 


DDMS Programmer Install: 5 GB (Program Files & Database) 


Software 


Running multiple instances of DDMS is not supported. 
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3. 1.2. 5 Multi-Channel Device Driver (MCDD) 

For larger systems, an Application Server can be connected to a maximum of 16 control stations. 
Each control station is configured to communicate on the specified channel, and acts as the data 
gateway for that channel. The MCDD keeps track of which interface each radio is currently using. 
Each control station is handled like a different network interface to the Application Server. When 
the MCDD sees a registration or other data traffic from a radio, it updates the routing table of the 
Application server. In this manner, any data traffic targeted towards that radio is routed through the 
correct network interface, therefore through the correct control station and channel. This allows 
data applications to simply transmit a data message to the radio, and the MCDD routes the data to 
the correct channel. The MCDD is typically installed on the same server that runs the Presence 
Notifier application. 

When in Capacity Plus or Linked Capacity Plus modes, the MCDD should not be installed because 
the data messages from the Application Server are not sent via the Revert Control Stations, but 
instead via the Trunked Control Stations. In Conventional mode, a radio registers with the 
Presence Notifier application on change in the home channel. The MCDD uses the registration to 
remember the current home channel of the radio and directs the data messages for the radio to 
the control station connected to the radio’s home channel. This is not possible in Capacity Plus, 
because the MCDD is not aware of the current Rest Channel. In Capacity Plus/Linked Capacity 
Plus, data messages transmitted to a radio are routed to Trunked Control Stations and all idle 
trunked control stations are on the Rest Channel. 

The MCDD is not required with the MNIS application. 

3.1 .2.6 Text Messaging Application 

The MOTOTRBO Text Messaging, a Windows PC-based application extends the radios' in-built 
text messaging services to mobile and central dispatch PC users. It also provides access to an 
important additional service: e-mail messaging to radio users. The MOTOTRBO Text Messing 
application consists of the Text Messaging Server, the Dispatch Text Messaging Client, and the 
Mobile Text Messaging Client. 

3. 1.2. 6.1 Text Messaging Client 

The Text Messaging computer software controls all text messaging services. The Graphic User 
Interface (GUI) provides fully transparent operation to users; it allows them to send and receive 
messages without needing to manually operate any other equipment within the MOTOTRBO text 
messaging service. There are two versions of the text messaging clients. One is installed at a fixed 
location such as a dispatcher's workstation, while the other is installed in a mobile location such as 
a laptop connected to a MOTOTRBO radio. 

Users may be organized into logical groups to make the distribution of messages to multiple 
destinations easy. This gives full control of the management of complex message distribution to 
each user. 
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3. 1.2. 6. 2 Text Messaging Client Computer Specifications 



Component 


Requirements 


Processor 


Pentium III operating at 1 GHz or higher. 


Memory 


Minimum 256MB. 512 MB and above recommended. 


Hard Disk 


1 GB free space for installation. Beyond this additional space as required for 
data. 1 GB can store up to 150000 messages. Recommended: Total 3GB of free 
space. 


Network 


1 0M/1 00M Ethernet Interface Card (Only for Fixed End Client) 


Operating System 


Windows 2000, SP4 OR Windows XP Professional, SP2 


Web Browser 


Internet Explorer 5.5 or later required for printing. 



3. 1.2. 6. 3 Text Messaging Server 

The Text Messaging Server provides the message processing and interfaces with various sub- 
systems. The text messaging server can also act as a gateway to an e-mail domain. Through the 
text messaging server, external e-mail users can send e-mails to radios and dispatchers. An e- 
mail application and host will have to be provided in addition to the text messaging server. The text 
messaging server is based on the Microsoft SQL Server 2000 Desktop Engine (MSDE 2000) 
database server. Typically, the text messaging server is deployed in a Windows environment. The 
server also contains the Messaging Server Administrative Utilities. These utilities provide the 
Windows GUI and browser-based interfaces to allow a Messaging System Administrator to 
operate, maintain and administer the Messaging System product. 

3. 1.2. 6.4 Text Messaging Server Administrative Client 

The text messaging server administrative utility provides the configuration management function. 
In general, there are two types of configuration that should be done by Messaging System 
Administrator: Server Configuration and Client Configuration. The Server Configuration is divided 
into System Configuration and Runtime Configuration. In general, the server should be configured 
first, then the client. After both are configured, the administrator should publish and distribute the 
client configuration file to all clients. 
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3.1 .2.6.5 Text Messaging Server Computer Specifications 



Component 


Requirements 


Processor 


1GHz Pentium Ill-class and above processor recommended. 


Memory 


Minimum 256MB. 512 MB and above recommended. 


Hard Disk 


Minimum 1 GB. 80 GB and above available space recommended. 


Network 


1 00 Mbps or Gigabit Ethernet interface. 


Operating System 


Windows XP Professional (SP2) or Windows 2000 Professional (SP4) 


Message Queuing 


Windows Message Queuing Services installed and running. 


Internet Information 
Services 


Internet Information Services (IIS) - IIS 5.0 installed (Windows 2003) or IIS 5.1 
installed (Windows XP Professional). 


Web Browser 


Recommended Microsoft Internet Explorer Version 6 or later. 


.NET software 


.NET 1.1 framework installed and running. 


Hardware Required 


Up to 16 distinct USB ports are required. Hubs are supported. 



3.1 .2.7 MotoLocator Location Tracking Server 

The MotoLocator server is a software package that can request, receive and store location data 
that MOTOTRBO radios extract from their on-board GPS chipsets. This information is kept in a 
database and can be extracted by mapping software for easy viewing. The MotoLocator Tracking 
Server can be installed on the same server as the Text Messaging Server. 

The location tracking application is not supported in Capacity Plus systems and comprises of three 
parts: 



• The MOTOTRBO radio with an internal GPS chip 

• The Location Server 

• The Location Client 

MOTOTRBO radios can be ordered equipped with GPS chips. When requested by the Location 
Server, the radio retrieves the location data from its internal GPS chip, and transmits it to the 
Location Server. The Location Server stores the location information for each radio in a database. 
This database information can then be accessed by a Location Mapping Client. The Location 
Mapping Client can view and track the location of multiple radios on a map. 

The periodic update rate at which the radios send in their GPS coordinates is centrally configured 
via the Location Server. Radios can be configured to immediately send in their coordinates if they 
initiate an emergency. 

The location information can also be made available to other applications via a standard API. This 
allows location data to be displayed through a mapping interface, or to be used by other decision- 
making applications. MotoLocator offers a Web Services API that allows for fast integration to 
broader technology landscapes and systems. 
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3. 1 .2.7. 1 Location Server Computer Specifications 



Component 


Requirements 


Processor 


1GHz Pentium Ill-class and above processor recommended. 


Memory 


Minimum 256MB. 512 MB and above recommended. 


Hard Disk 


Minimum 1 GB. 80 GB and above available space recommended. 


Network 


1 00 Mbps or Gigabit Ethernet interface. 


Operating System 


Windows XP Professional (SP2), Windows 2000 Professional (SP4) 


Message Queuing 


Windows Message Queuing Services installed and running. 


Internet Information 
Services 


Internet Information Services (IIS) - IIS 5.0 installed (Windows 2003) or IIS 5.1 
installed (Windows XP Professional). 


Web Browser 


Recommended Microsoft Internet Explorer Version 6 or later. 


.NET software 


.NET 1.1 framework installed and running. 


Hardware Required 


Up to 16 distinct USB ports are required. Hubs are supported. 



3. 1.2. 7. 2 MOTOTRBO Location Client 

The MOTOTRBO Location Client is an easy-to-use mapping solution for the enterprise and public 
safety sectors. It functions as a mapping client for the MotoLocator, and enables the display and 
monitoring of resource locations on digital maps and photographs. The location client can display 
a resource position on a map, and can track its status. The client also offers geocoding, reverse 
geocoding, point of interest definition, and fastest path routing. It integrates with the MOTOTRBO 
Text Messaging Client for two-way communication with resources. Both the Location Client and 
the Text Messaging Client can be installed on the same PC. The location client allows dispatchers 
to login and track only specific resources/groups of interest, as well as allow the setting of cadence 
and polling of resources. The client allows the definition of multiple geofences, and warns the 
dispatcher when a resource enters/exits them. 
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3.1 .2.7.3 Location Client Computer Specifications 



Component 


Requirements 


Processor 


1GHz Pentium Ill-class and above processor recommended. 


Memory 


Minimum 256MB. 512 MB and above recommended. 


Hard Disk 


1 GB free space for installation. Beyond this additional space as required for 
data. 1 GB can store up to 150000 messages. 

Recommended: Total 3GB of free space. 


Network 


1 0M/1 00M Ethernet Interface Card (Only for Fixed End Client). 


Operating System 


Windows 2000, SP4 OR Windows XP Professional, SP2. 


Web Browser 


Recommended Microsoft Internet Explorer Version 6 or later. 



3.2 System Topologies 

The primary element in the design of any private two-way radio communications system is the 
networking of a fleet of field radios (portable and mobile radios). To set up such a system, the 
following questions should be asked: 

• How many system users require a field radio? 

• Which system users need to communicate with each other? 

• Where are system users transmitting and receiving from when communicating with other 
system users? 



This information becomes the basis in determining the extent of the required system coverage 
area, and the creation of its topologies. This information and the desired feature set determines 
decisions on the system’s topology. 
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3.2.1 Direct Mode/Dual Capacity Direct Mode (DCDM) 

If, within the customer’s required coverage area, any system user can directly communicate with 
all of the other system users with just the output power of the transmitter in their portable or mobile 
radio, then a direct mode or dual capacity direct mode system can be used. Direct mode or dual 
capacity direct mode is direct radio-to-radio communication for systems that do not use a repeater. 
When radios operate in direct mode/dual capacity direct mode, the radios always transmit and 
receive on the same frequency. Direct mode and dual capacity direct mode provide similar 
services to the end users, with the exception that dual capacity direct mode is only available in 
digital mode, and supports two simultaneous voice/data paths on a 12.5 kHz bandwidth channel 
while direct mode supports only one. Additionally, there are some minor differences. For example, 
dual capacity direct mode channels may not be used as GPS revert channels. 

The radios are not limited to one direct mode/dual capacity direct mode frequency. They can be 
programmed to have different frequencies, which are selectable with the channel selector knob. 

Direct mode/dual capacity direct mode do not need over-the-air hang time for voice calls (See 
“Repeater” on page 185). The radio has an internal call (“talk back”) timer. The channel access 
method used before the call timer expires is impolite, since the radio is still a member of an active 
call. This is independent of the Channel Access selection for call initiation (polite or impolite). 

3. 2. 1.1 Digital MOTOTRBO Radios in Direct Mode/Dual Capacity 
Direct Mode 




MOTOTRBO SU MOTOTRBO SU 

(digital mode) (digital mode) 



Figure 3-7 MOTOTRBO Radios (in digital mode) In Direct Mode/Dual Capacity Direct Mode 

In direct mode/dual capacity direct mode configuration, a single frequency is assigned to all radios 
to communicate with each other. In digital direct mode/dual capacity direct mode, the radios 
support all three methods of voice transmission: Group Calls, Private Calls and All Calls. They can 
also support all command and control messaging like Call Alert, Radio Check, Radio Enable/ 
Disable, Remote Monitor and Emergency. 
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3.2. 1.1.1 Text Messaging in Direct Mode/Dual Capacity Direct Mode 



TX = fi 
RX = fi 




TX = fi 
RX = fi 



MOTOTRBO SU MOTOTRBO SU 

(digital mode) (digital mode) 

Figure 3-8 MOTOTRBO Radios (in digital mode) Text Messaging In Direct Mode/Dual Capacity Direct 

Mode 

In direct mode/dual capacity direct mode, the MOTOTRBO radios are capable of sending text 
messages to other radios. Radio to radio text messaging is accomplished by a text messaging 
application that is built into the radio. From the front keypad, the radio user can select the target 
radio, and type a text message. 

In order for the text message to be sent successfully to the target radio, both radios need to be on 
the same frequency. Similar to voice, if multiple direct mode/dual capacity direct mode frequencies 
are being used, the user must choose the channel his target is on before sending his text 
message. The radios do not have to be on the same group. 

Text messaging and the previously discussed voice services operate on the same frequency. 
Since data operates in a polite manner, the radio avoids transmitting text messages while any 
voice service is active. If operating with only field radios, text messages are limited to radio to radio 
communications. 

Text messages can also be sent from radio to radio using a PC attached to the radio. A software- 
based text messaging client will be installed on the PC. These configurations are commonly used 
in vehicles or on desktops that do not have LAN connections. Since they can run on AC power or 
off the in-vehicle battery, mobile radios are usually used for these applications, though a portable 
can also be used. Note that the radio can be configured to route incoming text messages to itself 
or to the PC, but not both. 
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Figure 3-9 MOTOTRBO Radios (in digital mode) Text Messaging In 
Multiple Direct Mode/Dual Capacity Direct Mode 

3. 2. 1.1. 2 Telemetry Commands in Direct Mode/Dual Capacity Direct Mode 



Below are some basic telemetry configurations, each with a quick description. 




MOTOTRBO SU 
(digital mode) 




MOTOTRBO SU 
(digital mode) 



(Customer Provided) 



Figure 3-10 Send Telemetry Command from MOTOTRBO Radio to Another MOTOTRBO Radio to Toggle 

an Output Pin 

In the first basic configuration, a portable radio is programmed with a button that sends a pre- 
configured telemetry command over-the-air to toggle a mobile radio’s output GPIO pin. The GPIO 
pin is connected to external hardware that detects this change at the GPIO pin, and turns on a 
light. This configuration can be extended to other applications like remotely opening door locks, 
turning on pumps, or switching on sprinklers. Another application might be to combine the voice 
from the radio’s external audio lines, a relay closure, and a public announcement system to 
remotely make announcements over the intercom from your portable radio. 
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Figure 3-1 1 Send Telemetry Message from MOTOTRBO Radio to Another MOTOTRBO Radio when Input 

Pin State Changes 

This second basic configuration is a mobile that is connected to a customer supplied external 
telemetry hardware, which sends an event to one of the mobile’s GPIO pins when it detects that a 
particular door has been opened. Upon detecting the GPIO pin as active, it sends a pre-configured 
Text Status Message to a particular portable radio. The portable radio displays “Door Opened” to 
the user as a popup alert. This basic configuration can be used at remote locations to detect a 
variety of sensors such as water levels, door and window intrusions, or even motion sensors. 
Combining the first and second configuration, the user can create complex control systems that 
initiates a large door to close, and then announces when the door physically closes. 




(Customer Provided) M0T0TRB0 S U MOTOTRBO SU ( Customer Provided > 



(digital mode) (digital mode) 

Figure 3-12 Send Telemetry Command to Toggle an Output Pin from MOTOTRBO Radio to Another 

MOTOTRBO Radio when Input Pin State Changes 

The third basic configuration is a mobile that is connected to customer supplied external telemetry 
hardware, which sends an event to one of the mobile’s GPIO pins when it detects that a particular 
door has been opened. Upon detecting the GPIO pin as active, it sends a telemetry toggle 
command to another mobile radio. This mobile radio is configured to toggle an output pin, which is 
connected to telemetry hardware that sounds an alarm. Similar to the other configurations, this 
method can be extended to a myriad of other solutions such as only opening doors when other 
doors have been closed, or turning on water pumps when water levels reach a particular level. 






218 



System Components and Topologies 



This configuration can be used automate the environment of two remote locations. The 
possibilities are only limited by the designer’s imagination. 

3. 2. 1.1. 3 Server-Based Data Applications in Direct Mode/Dual Capacity 
Direct Mode 

MOTOTRBO also supports server based data applications in direct mode/dual capacity direct 
mode. This configuration consists of a PC (referred to as the Application Server) running the 
server software connected to the radio infrastructure via a mobile radio (or control station). The 
mobile radio is usually AC powered. The mobile is configured as a control station, therefore it 
routes all data to the Application Server. Since this mobile is the radio gateway to the server, it is 
configured to transmit and receive on a single channel. The control station is programmed with a 
known radio ID, so the field radios know how to contact the server. The server and the control 
station (connected via USB) must be located in the center of the customer’s coverage area since 
all field radios are expected to communicate with it. There can only be one Application Server per 
system. See “Application Server” on page 207 for the descriptions for the recommended hardware 
specifications for an Application Server. 

One key service offered by the server based configuration is radio presence notification. The 
Presence Notifier is required to reside on the Application Server. The purpose of the Presence 
Notifier is to track whether field radios are currently present on the system. Upon power-up or 
channel change, the MOTOTRBO radio transmits a registration message to the control station 
connected to the Application Server, where the Presence Notifier resides. The Presence Notifier 
then informs other data applications that the radio is available to receive and transmit data 
messages. 

The MOTOTRBO Location application requires a server-based configuration and the Presence 
Notifier to operate. The Location Server application is installed on the Application Server machine 
with the Presence Notifier. When a radio registers with the Presence Notifier, it informs the 
Location Server that this radio is now on the system. The Location Server then sends out a service 
availability message through the control station to the radio informing it how often to send in 
periodic updates, and what to do if an emergency is initiated. 

Location Dispatch applications request a radio’s location information from the Location Server 
application, and display the radio’s location on a map. A Location Dispatch application can reside 
on the Application Server as well. The diagram below depicts this configuration. 
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Figure 3-13 MOTOTRBO Radios In Digital Direct Mode/Dual Capacity Direct Mode with Location Server 

and Local Location Client 



Text Messaging also uses a server based configuration. Similar to the Location Server, the Text 
Message Server application is installed on the Application Server machine with the Presence 
Notifier. When a radio registers with the Presence Notifier, it informs the Text Message Server that 
the radio is now on the system. The Text Message Server then sends out a service availability 
message through the control station to the radio informing it how it can communicate with the Text 
Message Server. Text Message Dispatch applications communicate with the Text Message Server 
in order to send and receive messages to and from the radio network via the connected control 
station. A Text Message Dispatch application can reside on the Application Server as well. 

As previously described, radios can send text messages to each other without communicating 
through the Text Message Server. But in order to send and receive text messages to Text 
Message Dispatchers, the Text Message Server configuration is required. The diagram below 
depicts this configuration. This configuration also works with external text message applications 
connected to the field radios. 




Application Server 

Figure 3-14 MOTOTRBO Radios In Digital Direct Mode with Text Message Server, Location Server and 

Local Dispatchers 
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This configuration can be expanded by locating up to four Text Message Dispatchers and four 
Location Dispatchers throughout the customer’s Enterprise Network. Up to four installations of 
each application can be located anywhere on the customer’s LAN, as long as they can 
communicate with the Application Server. The Dispatcher installation on the Application Server 
counts as one of the instances of the dispatch software. The diagram below shows two instances 
of each application. One is on the Application Server and one remote. The applications can reside 
on the same remote machine, if desired. 




Figure 3-15 MOTOTRBO Radios In Digital Direct Mode/Dual Capacity Direct Mode Server Based 

Configuration with Remote Dispatchers 

Another Text Message service that is only available in a server based configuration is the ability to 
receive and send text messages to external e-mail addresses. This allows PCs or pagers and cell 
phones that are text message capable on the system to send e-mail messages. In order for the 
Text Message Server to communicate with the outside world, the Application Server must have 
access to the internet. When a radio sends a text message to a Text Message Dispatcher, and it is 
identified as an external e-mail address in the Text Message Server, the Text Message Server will 
forward the text message to the designated e-mail address. 

The Text Message Server forwards incoming e-mails in a similar fashion. The source e-mail 
address must be configured in the Text Message Server for it to forward the text messages to the 
destination radio. This blocks unknown e-mail traffic from utilizing the bandwidth of the radio 
system. 
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3. 2. 1.1. 4 Multi-Channel Server-Based Data Applications in 
Direct Mode/Dual Capacity Direct Mode 

For larger systems that have multiple direct mode/dual capacity direct mode frequencies, the 
Application Server can be connected to up to 16 control stations. Each control station is configured 
to communicate on the specified channel and acts as the data gateway for that channel. 

Presence registration works in the same manner with this configuration as it does with the single 
channel configuration. When a radio powers up or changes channels, it sends in a registration to 
the Presence Notifier via the control station, which then informs the applications of the radio’s 
presence. Each control station has the same radio ID, therefore the field radios transmit their 
messages to this radio ID regardless of which channel they are on. 

Because the field radios are located on different channels, the Multi-Channel Device Driver 
(MCDD) tracks the location of each radio, so outbound data from the Application Server can be 
routed to the appropriate channel. The MCDD is a small piece of software installed on the 
Application Server. Each control station is handled like a different network interface to the 
Application Server. When the MCDD sees a registration, it updates the PC’s routing table so that 
any data traffic for that radio is routed out the correct network interface, and therefore through the 
correct control station and over the correct channel. (Note: MCDD release R1.0 version 1.00.17 
also updates the routing table on receipt of any data traffic, making it incompatible with GPS 
Revert). This allows data applications to simply transmit a data message to the radio, and the 
MCDD takes care of the routing to the correct channel. 

Any channel, that supports data and needs to communicate to the Application Server, needs a 
dedicated control station. 
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Figure 3-16 MOTOTRBO Radios in Two Channel Digital Direct Mode Server-Based Configuration with 

Remote Dispatchers 
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3. 2. 1.1. 5 GPS Revert in Direct Mode/Dual Capacity Direct Mode 

With the addition of the GPS Revert feature, it is now possible to transmit Location Update 
messages on channels other than the Selected Channel (See “GPS Revert Channel” on page 58 
for configuration information). The diagram in Figure 3-17 illustrates this concept in its simplest 
form while operating in direct mode/dual capacity direct mode. The dual capacity direct mode 
operation is similar to direct mode in GPS revert scenarios, with the exception that a dual capacity 
direct mode channel can not be used as a GPS revert channel. As a result of that, a radio can 
revert from a dual capacity direct mode channel, but can not revert to a dual capacity direct mode 
channel to send the GPS update. In this example, Channel fl is the Selected Channel and 
Channel f2 is the GPS Revert Channel. Communications such as presence, location requests 
(Application Server to radio), text and voice occur on the Selected Channel, while all location 
responses (radio to Application Server) including location updates occur on the GPS Revert 
Channel. Therefore, a minimum of 2 control stations are required to support GPS Revert. 




Figure 3-17 MOTOTRBO Radios in Two Channel Direct Mode GPS Revert Configuration 

Under a typical scenario, the radio is powered on, and then registers on the Selected Channel with 
the Presence Notifier and the Location Server. The radio receives a Periodic Location Request 
and an Emergency Location Request from the Location Server on the Selected Channel. This 
Periodic Location Request instructs the radio to send location updates at a specific rate, while the 
Emergency Location Request instructs the radio to send a single Emergency Location Update 
when an emergency is initiated. 

The radio spends the most time on the Selected Channel. The radio only switches to the GPS 
Revert Channel when a Location Update needs to be transmitted. Since voice transmissions have 
priority over data transmissions, when the radio is involved in a call on the Selected Channel, the 
Location Update is queued until after the call is completed. In order to minimize the amount of time 
spent away from the Selected Channel while on the GPS Revert Channel, the radio will not 
attempt to qualify traffic on the GPS Revert Channel. Therefore, all voice, data, and control 
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messages transmitted to a radio should never be transmitted on the GPS Revert Channel, as they 
will not reach their destination. 

The example in Figure 3-17 illustrates only one GPS Revert Channel. However, depending on the 
GPS data load, more than one GPS Revert Channel may be needed. For example, a single large 
group that generates significant Location Update traffic must be sub-divided across several GPS 
Revert Channels. Each GPS Revert Channel requires a control station, which must be connected 
to the Application Server PC. The maximum number of control stations that can be connected to 
the PC is four. 

3 . 2 . 1 . 1. 6 Summary of Features in Digital Direct Mode/Dual Capacity Direct 
Mode (DCDM) 

The following features are supported in digital direct mode/dual capacity direct mode: 



Digital MOTOTRBO Radios in Direct Mode/Dual Capacity Direct Mode 
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*See “Scan Considerations” on page 76 for more information on the different scan modes 
supported by different topologies. 
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3.2.1 .2 Interoperability between Analog MOTOTRBO Radios and Analog 
Radios in Direct Mode 
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Figure 3-18 Legacy Analog Radios and MOTOTRBO Radios (in analog mode) in Direct Mode 



MOTOTRBO radios support analog mode as well. In order for the MOTOTRBO radio to 
communicate with an analog radio, it must be programmed for analog mode, as well as 
programmed with the same frequency and parameters (for example, PL and DPL) as the analog 
radio. While in analog mode, the MOTOTRBO radio supports most standard analog features 
including a subset of MDC signaling features. While in analog direct mode, the MOTOTRBO 
radios does not support any of the digital features. 

3. 2. 1.2.1 Summary of Features in Analog Direct Mode 



All features listed in “Analog Features” on page 167 are supported in analog direct mode. 
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3. 2. 1.3 Interoperability between Digital MOTOTRBO Radios, Mixed Mode 
MOTOTRBO Radios, and Analog Radios in Direct Mode 
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Figure 3-19 Legacy Analog and MOTOTRBO Analog and Digital Radios in Direct Mode 

In this configuration, a MOTOTRBO subscriber is programmed to talk to an analog radio as well as 
a MOTOTRBO radio that is programmed for digital only. 

In order for the MOTOTRBO radio to communicate with the analog radio, it must be programmed 
for analog mode, as well as programmed with the same frequency and parameters (for example 
PL and DPL) as the analog radio. 

When in the digital mode, the MOTOTRBO subscriber has all of the digital features that are 
available in digital direct mode. However, the MOTOTRBO radio user has to manually switch from 
digital mode to analog mode to communicate with the two groups. 

Alternatively, the MOTOTRBO radio user can program the radio to scan between the analog and 
digital channels to ensure a call is not missed. This can be done from the keypad of the radio or 
through the CPS. Please see “Scan” on page 73 and “Scan Considerations” on page 76 to learn 
more about scan. 

3. 2. 1.4 Direct Mode Spectrum Efficiency 

A radio frequency (RF) channel with 12.5 kHz spectrum allocation can be configured to support 
direct mode or dual capacity direct mode via CPS. 

When configured to support direct mode, the radio only utilizes a single timeslot for the traffic, 
while the other timeslot is unused, as shown in Figure 3-20. 



Single channel utilized for traffic Traffic Unused 
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Figure 3-20 Direct Mode Channels 
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When configured to support dual capacity direct mode, both timeslots can be used for two different 
calls. This yields dual capacity (2:1 TDMA) spectrum efficiency, as shown in Figure 3-21. The dual 
capacity direct mode configuration provides equivalent spectral efficiency when compared with 
ETSI-DMR repeater solutions and 6.25 kHz FDMA solutions. 



Both channels utilized for traffic Guard 
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Figure 3-21 Dual Capacity Direct Mode Channels 

3.2.2 Dual Capacity Direct Mode 

3.2.2. 1 General Information 

Dual capacity direct mode is a digital feature aimed to benefit end-users who do not have and do 
not need repeaters, by providing 6.25 kHz spectrum efficiency. When a 12.5 kHz RF channel is 
configured for dual capacity direct mode, both timeslots are available for independent and 
simultaneous radio call conversations. 

3. 2. 2. 2 Timeslot Synchronization 

Since there is no repeater designating a slotting structure and dual capacity direct mode uses both 
timeslots for the traffic, timeslot synchronization needs to be applied to differentiate timeslot 1 from 
timeslot 2. In the absence of a repeater, the radios in dual capacity direct mode automatically and 
cooperatively select a Channel Timing Leader (CTL) and synchronize to the leader’s channel 
timing. This CTL election process is transparent to the end user. For a 12.5 kHz RF channel, only 
one CTL is elected, that is, the same radio that provides the channel timing for both timeslots 
irrespective of radio timeslot provisioning and color code provisioning. The selected CTL 
periodically announces the channel timeslot structure via beacons, and the other radios 
synchronize with the leader directly or indirectly (via other radios) by following the synchronization 
information in these beacons. The dual capacity direct mode beacon transmits for 600 
milliseconds every 4.5 minutes. This only uses 0.22% of the channel capacity and should have 
little impact to other services. 

3. 2. 2. 3 Channel Timing Leader (CTL) Preference 

When operating in dual capacity direct mode, a radio’s preference to be a CTL can be CPS 
configured on a per channel basis as follows: 

• Preferred CTL: The radios that are always turned on, always selected to dual capacity 
direct mode channel, never scans or have large transmit coverage are “good” candidates to 
be the preferred CTL. Whenever possible, a mobile may act as the preferred CTL since 
synchronization beaconing may drain more battery capacity. 

• Normal Preference: The default configuration that allows a radio to act as the CTL, but 
should yield leadership to higher preference candidates. 

• Least Preferred: This option is not CPS selectable, but is automatically selected when a 
scan list is attached to the selected dual capacity direct mode channel. 
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• Ineligible: This option may be selected in radios that are “bad” candidates to be a CTL. For 
example, radios that change channels often, or roam often, and so on, but at least one radio 
must not be “Ineligible”. 

To avoid frequent CTL re-election, it is recommended to assign the same CTL preference to all 
dual capacity personalities that use the same frequency when configuring a specific radio. 

3. 2. 2.4 Color Code 

Similar to direct mode operation, in dual capacity direct mode, color code 0-14 are specified on a 
per timeslot (channel) basis via CPS provisioning. Color code 15 is reserved for future usage and 
not available for dual capacity direct mode channels. Different color codes can be used in the two 
timeslots of an RF channel. 

3. 2. 2. 5 Channel Access Rule 

Dual capacity direct mode channel access rules are specified on a timeslot (channel) basis via 
CPS provisioning. The channel access in dual capacity direct mode follows the same rules as 
defined in Section 2.2.3 “MOTOTRBO Channel Access”. 

3. 2. 2. 6 Scan 

To enable migration and interoperability, a dual capacity direct mode channel can have a scan list 
that includes a non-dual capacity direct mode channel, and a non-dual capacity direct mode 
channel can have a scan list that includes a dual capacity direct mode channel. Therefore, a scan 
list may include a mixture of dual capacity direct mode and direct mode channels as well as analog 
and repeater channels. If talkback is enabled and the radio lands on a dual capacity direct mode 
channel, the radio can talk back in dual capacity direct mode in the proper timeslot. 

There may be up to sixteen (16) channels in a scan list, among which the radio uses the DTC to 
track the channel timeslot structure. The choices for the DTC are: selected channel, last active, or 
other designated channel. In order for the selected DTC to be easily tracked, it is recommended to 
use the “selected channel” as the DTC and enable “Talkback”, especially when the selected 
channel is a dual capacity direct mode channel. 

3. 2. 2. 7 Interoperability and Backward Compatibility 

A radio may be CPS configured to operate in repeater mode, direct mode, dual capacity direct 
mode, or talkaround mode on different personalities. Direct mode is not as efficient as dual 
capacity direct mode in spectrum usage. However, it is still supported so that the radio is 
interoperable with other ETSI-DMR compatible radio and is backward compatible with software 
versions R02.00.00 or earlier, which can only support direct mode. 

A radio operating in dual capacity direct mode is not interoperable with a radio operating in 
repeater mode, direct mode, or talkaround mode. The radio treats the other radio’s transmission 
as interference. 
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3. 2. 2. 8 Revert Features 

A radio does not monitor the GPS revert channel hence it does not track the channel timeslot 
structure on the GPS revert channel. Therefore, dual capacity direct mode channels can not be 
used as GPS revert channels. 

A radio that is selected to a dual capacity direct mode channel may revert to emergency revert 
channels, or GPS revert channels, or enhanced GPS revert channels. 

3.2.3 Repeater Mode 

There are a few reasons why a customer may require a repeater in their system. The first is, if the 
required coverage area is large, they may require strategically located high power repeaters in 
order to cover all of their operating space. Even if their required coverage area is small, due to 
geographical limitations such as mountains, valleys or man made obstructions, they may still need 
multiple high power repeaters to reach all the coverage areas. They also may need the extra 
bandwidth a repeater offers. One channel may not be able to support a large number of users; 
therefore additional channels may be required. 

In many of these cases, the insertion of a MOTOTRBO repeater can alleviate the problems with 
minimum additional cost. Such a repeater is transparent to field radio communications. They just 
select the required channel using their channel selector, and continue their normal 
communications. However, as in most conventional systems, if the repeater coverage does not 
overlap, the user needs to know his location, and switch to the other channel when required. 

Even just having one MOTOTRBO repeater provides increased user capacity. The digital repeater 
operates in TDMA which essentially divides one channel into two virtual channels in digital mode; 
therefore the user capacity doubles. Without the repeater, this TDMA synchronization is not 
possible. The repeater utilizes embedded signaling to inform the field radios of the status of each 
channel (time slot). It informs the field radios of each channel’s busy/idle status, the type of traffic, 
and even the source and destination information. 

Another advantage during digital operation is error detection and correction. The further a 
transmission travels, the more interference it encounters, and inevitably more errors are 
introduced. The receiving MOTOTRBO radio, operating in digital mode, utilizes built-in error 
detection and correction algorithms, native to the protocol, to correct these problems. The 
MOTOTRBO repeater uses the same algorithms to correct the errors prior to retransmission, thus 
repairing any errors that occur on the uplink; it then transmits the repaired signal on the downlink. 
This greatly increases the reliability and audio quality in the system, which increases the 
customer’s coverage area. 

In digital mode, the repeater only retransmits digital signals from radios configured with the same 
system identifier. This aids in preventing co-system interference. The repeater does not block 
transmissions of radios within its own system. 

As previously described, the repeater utilizes embedded signaling to announce the current status 
of each channel. It is up to the radios in the field to interpret these signals, and grant or deny their 
user’s request for transmission. Therefore, when a user or a group of users utilizes a channel (time 
slot), the repeater announces that the channel is being used and who is using it. Only radios that 
are part of that group are allowed to transmit. The repeater additionally allows a short duration of 
reserved time after a transmission. This allows other users in the group to respond to the 
originator. This reserved hang time greatly increases the continuity of calls, because new calls 
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cannot start until the previous call ends. Without this feature, users may experience delays in 
responses (that is, between transmissions of calls), due to other calls taking over the channel in- 
between their transmissions. 

After this reserved hang time, the repeater stays active for a short period of time, and offers an 
opportunity for any user on the system to transmit or start a new call. If no user transmits for a 
duration of time, the repeater stops transmitting. When the next radio transmission occurs, the 
repeater starts repeating again. 

Most of the basic MOTOTRBO voice and data services work the same in repeater mode as they 
do in direct mode/dual capacity direct mode. The customer will only notice the increased 
performance and coverage. 

3.2.3. 1 Digital MOTOTRBO Radios in Repeater Mode 
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Figure 3-22 MOTOTRBO Digital Radios on MOTOTRBO Two-Slot Digital Repeater 



In digital mode, a repeater uses one frequency pair (1-transmit, 1 -receive) to support the two 
logical channels. As mentioned before, this is done by using TDMA technology to divide the 
physical channel into two time slots. In order to access the repeater, the radio user selects the 
physical and logical channel using the channel selector. Hence, when operating in repeater mode, 
the field radios cannot dynamically choose a time slot. Each of the channel selector positions is 
programmed for a particular digital frequency and time slot. The end user sees, in effect, each time 
slot as a different conventional channel. Radio groups can be further segmented within the time 
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slot by assigning different group IDs to each group. Groups on different time slots cannot 
communicate with each other. 

Synchronization is the key to a MOTOTRBO repeater system. It is the role of the repeater to keep 
this synchronization. When accessed, the repeater begins transmitting idle messages as well as 
identifying the time slot structure. The radios synchronize to the transmissions from the repeater. 
When a radio transmits on its time slot, the radio pulses its transmissions in 30ms increments. This 
allows for simultaneous conversation to occur on the other time slot. While the first radio is pulsed 
on, the other radio is pulsed off. The repeater receives these two pulsed transmissions, combines 
them and transmits them in the correct order in one continuous transmission. 

Repeater operation supports all three methods of voice transmission: Group Calls, Private Calls 
and All Calls. They can also fully support all command and control messaging like Call Alert, Radio 
Check, Radio Enable/Disable, Remote Monitor and Emergency. 
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3. 2. 3.1 .1 Text Messaging in Repeater Mode 
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Figure 3-23 MOTOTRBO Radios in Digital Two-Slot Digital Repeater Mode with Built-In Text Messaging 

In repeater mode, the MOTOTRBO radios are capable of sending text messages to other radios. 
Radio to radio text messaging is accomplished by a text messaging application that is built into the 
radio. From the front keypad, the radio user can select the target radio, and type a text message. 

In order for the text message to be sent successfully to the target radio, both radios need to be on 
the same channel and time slot. Similar to voice, if multiple direct mode/dual capacity direct mode 
frequencies are being used, the user must choose the channel his target is on before sending his 
text message. The radios do not have to be on the same group. 

Text messaging and the previously discussed voice services operate on the same channel and 
time slot. Since data operates in a polite manner, the radio avoids transmitting text messages 
while any voice service is active. If operating with only field radios, text messages are limited to 
radio to radio communications. 

Text messages can also be sent from radio to radio using a PC attached to the radio. A software- 
based text messaging client will be installed on the PC. These configurations are commonly used 
in vehicles or on desktops that do not have LAN connections. Since they can run on AC power or 
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off the in-vehicle battery, mobile radios are usually used for these applications, though a portable 
can also be used. Note that the radio can be configured to route incoming text messages to itself 
or to the PC, but not both. 




Mobile PC MOTOTRBO SU MOTOTRBO SU Mobile PC 

Terminal (digital mode) (digital mode) Terminal 



Figure 3-24 MOTOTRBO Radios in Digital Two-Slot Digital Repeater Mode with Text Messaging 
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3. 2. 3. 1.2 Telemetry Commands in Repeater Mode 

Below are some basic telemetry configurations using both time slots of a repeater. A description of 
each follows. 
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Figure 3-25 MOTOTRBO Radios in Digital Two-Slot Digital Repeater Mode with Telemetry Functions 

In the first basic configuration a portable radio is programmed with a button (shown by the pointing 
finger above) that sends a preconfigured telemetry command over-the-air on the second time slot 
to toggle a mobile radio’s output GPIO pin. The GPIO pin is connected to external hardware that 
detects the closure and turns on a light (shown by a light bulb above). This configuration can be 
extended to such things as remotely opening door locks, turning on pumps, or switching on 
sprinklers. Another application might be to combine the voice from the radio’s external audio lines, 
a relay closure, and a public announcement system to remotely make announcements over the 
intercom from your portable radio. 

This second basic configuration is a mobile configured on the second time slot, connected to 
customer supplied external telemetry hardware (shown by the door icon in lower right corner), 
detects a closure that signifies a door has been opened. Upon detecting the GPIO pin as active, it 
sends a pre-configured Text Status Message to a particular portable radio. The portable radio 
displays “Door Opened” to the user as a popup alert. This basic configuration can be used at 
remote locations to detect a variety of sensors such as water levels, door and window intrusions, 
or even motion sensors. Combining the first and second configuration, the user can create 
complex control systems that initiates a large door to close, and then announces when the door 
physically closes. 
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The third basic configuration is a mobile configured on the first time slot, connected to customer 
supplied external telemetry hardware, detecting a closure that signifies a door has been opened 
(shown by door in upper right corner). Upon detecting the GPIO pin as active, it sends a telemetry 
toggle command to another mobile radio on the first time slot. This mobile radio is configured to 
toggle an output pin which is connected to telemetry hardware that sounds an alarm (shown by 
alarm on upper left corner). Similar to the other configurations, this method can be extended to a 
myriad of other solutions such as only opening doors when other doors have been closed or 
turning on water pumps when water levels reach a particular level. This configuration can be used 
automate the environment of two remote locations together. The possibilities are only limited by 
the designer’s imagination. 

3. 2. 3. 1.3 Server Based Data Applications in Repeater Mode 

MOTOTRBO also supports server based data applications in repeater mode. This configuration 
consists of a PC (referred to as the Application Server) running the server software connected to 
the radio infrastructure via a mobile radio or via the MNIS application. For details on data 
communication with applications through the repeater network interface instead of a control 
station, refer to the MOTOTRBO Network Interface Service (MNIS) and MOTOTRBO Device 
Discovery and Mobility Service (DDMS) sections. 

The mobile radio is usually AC powered. The mobile is configured as a control station, therefore it 
routes all data to the Application Server. Since this mobile is the radio gateway to the server, it 
should be configured to transmit and receive on a single channel (frequency and time slot). The 
control station is programmed with a known radio ID so the field radios know how to contact the 
server. The server and the control station (connected via USB) must be located in an area that is in 
good coverage of the repeater it is communicating with. If there are multiple repeaters covering a 
large geographical area, the Application Server’s control stations must be located in good 
coverage of each repeater. This is important since it is common for the overlap between repeaters 
to be small and often only in low signal strength areas. There can only be one Application Server 
per system. See “Application Server” on page 207 for the descriptions for the recommended 
hardware specifications for an Application Server. 

One key service offered by the server based configuration is radio presence notification. The 
Presence Notifier is required to reside on the Application Server. The purpose of the Presence 
Notifier is to track whether field radios are currently present on the system. Upon power-up or 
channel change, the MOTOTRBO radio transmits a registration message to the control station 
connected to the Application Server, where the Presence Notifier resides. The Presence Notifier 
then informs other data applications that the radio is available to receive and transmit data 
messages. 

Each frequency and time slot that needs to communicate with the Application Server needs to 
have its own control stations. The Application Server can be connected to up to 16 control stations. 
Each control station is configured to communicate on the specified frequency and time slot and 
acts as the data gateway for that channel. Therefore a MOTOTRBO system can support server 
based data on up to two repeaters, each with two time slots. 

When a radio powers up or changes channels it sends in a registration to the Presence Notifier via 
the control station on its frequency and time slot, which in turn informs the applications of the 
radio’s presence. Each control station has the same radio ID, therefore the field radios transmit 
their messages to the same radio ID regardless of which frequency and time slot they are on. 
Because the field radios are located on different time slots, there needs to be a method to track the 
location of each radio so that outbound data from the Application Server can be routed to the 
appropriate time slot. This is the purpose of the Multi-Channel Device Driver (or MCDD). The 
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MCDD is a small piece of software installed on the Application Server. Its purpose is to keep track 
of which interface each radio is currently located on. Each control station is handled like a different 
network interface to the Application Server. When the MCDD sees a registration from a radio, it 
updates the PC’s routing table so that any data traffic targeted towards that radio will be routed out 
the correct network interface, therefore out the correct control station and over-the-air frequency 
and time slot. (Note: MCDD release R1.0 version 1.00.17 also updated the routing table on receipt 
of any data traffic, making it incompatible with GPS Revert). This allows data applications to simply 
transmit a data message to the radio and the MCDD takes care of the routing to the correct 
frequency and time slot. 

Any channel that supports data and needs to communicate to the Application Server needs a 
dedicated control station. Below is a diagram of this configuration. 
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Figure 3-26 MOTOTRBO Radios in Digital Two-Slot Digital Repeater Mode with a Server-Based 

Configuration Using Control Stations 

The MOTOTRBO Location application requires a server-based configuration and the Presence 
Notifier to operate. The Location Server application can be installed on the Application Server 
machine with the Presence Notifier. When a radio registers with the Presence Notifier, it informs 
the Location Server that this radio is now on the system. The Location Server then sends out a 
service availability message through the control station to the radio informing it how often to send 
in its periodic updates and what to do if an emergency is initiated. 

Location Dispatch applications request a radio’s location information from the Location Server 
application, and display the radio’s location on a map. A Location Dispatch application can reside 
on the Application Server as well. 
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Text messaging also uses a server based configuration. Similar to the Location Server, the Text 
Message Server application can be installed on the Application Server machine with the Presence 
Notifier. When a radio registers with the Presence Notifier, it informs the Text Message Server that 
the radio is now on the system. The Text Message Server then sends out a service availability 
message through the control station to the radio informing it how it can communicate with the Text 
Message Server. Text Message Dispatch applications communicate with the Text Message Server 
in order to send and receive messages to and from the radio network via the connected control 
station. Like the Location Dispatch, the Text Message Dispatch application can reside on the 
Application Server too. 

As previously described, radios can send text messages to each other without communicating 
through the Text Message Server. But in order to send and receive text messages to Text 
Message Dispatchers, the Text Message Server configuration is required. This configuration also 
works with external text message applications connected to the field radios. 

This configuration can be expanded by locating up to four Text Message Dispatchers and four 
Location Dispatchers throughout the customer’s Enterprise Network. Up to four installations of 
each application can be located anywhere on the customer’s LAN, as long as they can 
communicate with the Application Server. The Dispatcher installations on the Application Server 
counts as one of the instances of the dispatch software. The diagram below shows 2 instances of 
each application. One is on the Application Server and one remote. The applications can reside on 
the same remote machine, if desired. 
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Figure 3-27 MOTOTRBO Radios in Digital Two-Slot Digital Repeater Mode with a Server-Based 
Configuration Using Control Stations and Remote Dispatchers 

Another Text Message service that is only available in a server based configuration is the ability to 
receive and send text messages to external e-mail addresses. This allows PCs or pagers and cell 
phones that are text message capable on the system to send e-mail messages. In order for the 
Text Message Server to communicate with the outside world, the Application Server must have 
access to the internet. When a radio sends a text message to a Text Message Dispatcher, and it is 
identified as an external e-mail address in the Text Message Server, the Text Message Server will 
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forward the text message to the designated e-mail address. It requires access to the internet in 
order to send the message. 

The Text Message Server also forwards incoming e-mails in a similar fashion. The source e-mail 
address must be configured in the Text Message Server for it to forward the text messages to the 
destination radio. This blocks unknown e-mail traffic from utilizing the bandwidth of the radio 
system. 

On the following page is an example of a server based configuration that supports four data 
capable time slots with local and remote dispatchers. Note that any mix of external and internal 
radio Text Message Clients are supported on each channel. 





System Components and Topologies 



239 




Figure 3-28 MOTOTRBO Radios in Digital Two-Slot, Digital Repeater Mode with Text Message Server, 
Location Server Using Control Stations with Local and Remote Dispatchers 
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3. 2. 3. 1.4 GPS Revert in Repeater Mode 

With the addition of the GPS Revert feature, it is now possible to transmit Location Update 
messages on channels other than the Selected Channel (See “GPS Revert Channel” on page 58 
for configuration information). The diagram in Figure 3-29 illustrates this concept in its simplest 
form while operating in repeater mode. In this example, channels flsl and f2s1 compose the 
Selected Channel frequency pair and channels f1s2 and f2s2 compose the GPS Revert Channel 
frequency pair. Communications such a presence, location requests (Application Server to radio), 
text and voice occur on the Selected Channel, while all location responses (radio to Application 
Server) including location updates occur on the GPS Revert Channel. Therefore, a minimum of 2 
control stations are required to support GPS Revert. 




Figure 3-29 MOTOTRBO Radios in Two-Slot Digital Repeater Mode with GPS Revert Configuration 

For details on data communication with applications through the repeater network interface 
instead of a control station, refer to the MOTOTRBO Network Interface Service (MNIS) and 
MOTOTRBO Device Discovery and Mobility Service (DDMS) sections. 

Under a typical scenario, the radio is powered on, and then registers on the Selected Channel with 
the Presence Notifier and the Location Server. The radio receives a Periodic Location Request 
and an Emergency Location Request from the Location Server on the Selected Channel. This 
Periodic Location Request instructs the radio to send location updates at a specific rate, while the 
Emergency Location Request instructs the radio to send a single Emergency Location Update 
when an emergency is initiated. 

The radio spends the most time on the Selected Channel. The radio only switches to the GPS 
Revert Channel when a Location Update needs to be transmitted. Since voice transmissions have 
priority over data transmissions, when the radio is involved in a call on the Selected Channel, the 
Location Update is queued until after the call is completed. In order to minimize the amount of time 
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spent away from the Selected Channel while on the GPS Revert Channel, the radio will not 
attempt to qualify traffic on the GPS Revert Channel. Therefore, all voice, data, and control 
messages transmitted to a radio should never be transmitted on the GPS Revert Channel, as they 
will not reach their destination. 

The example in Figure 3-29 illustrates only one GPS Revert Channel. However, depending on the 
GPS data load, more than one GPS Revert Channel may be needed. For example, a single large 
group that generates significant Location Update traffic must be sub-divided across several GPS 
Revert Channels. Each GPS Revert Channel requires a control station, which must be connected 
to the Application Server PC. The maximum number of control stations that can be connected to 
the PC is four. 

3. 2. 3. 1.5 Enhanced GPS Revert in Repeater Mode 

This section provides the recommended system topologies for the Enhanced GPS Revert feature 
in Single Site, Capacity Plus, Linked Capacity Plus and IP Site Connect modes of operation. 

3. 2. 3. 1.5.1 Single Site Conventional 

Figure 3-30 is a system configuration that shows how the Enhanced GPS Revert feature can be 
used in single site mode operation. It is assumed that the repeater has slot one configured for 
Voice, Text and ARS data and slot two for location responses. When a radio powers on, the radio 
registers on the Home channel with the Presence Notifier, which notifies the Location Server. All 
outbound data from the server (including location request) is routed on the Home channel whereas 
all location responses are on the Enhanced GPS Revert channel. There should not be any non- 
GPS traffic on the GPS Revert channel as it affects GPS reliability. Voice calls on an Enhanced 
GPS Revert channel are not repeated. 
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Figure 3-30 Single Site Conventional System with an Enhanced GPS Revert Channel 



For details on data communication with applications through the repeater network interface 
instead of a control station, refer to the MOTOTRBO Network Interface Service (MNIS) and 
MOTOTRBO Device Discovery and Mobility Service (DDMS) sections. 



A user may also configure both slots of the repeater for enhanced GPS via the CPS. In this 
scenario, the user needs another repeater for voice and regular data, because only GPS data is 
supported on slots configured with Enhanced GPS. 








System Components and Topologies 



243 



3. 2. 3. 1.5. 2 IP Site Connect Mode 

Figure 3-31 shows a typical IP Site Connect system where slot 2 of all the repeaters have been 
configured as a wide area Enhanced GPS Revert channel and slot 1 as the Home channel. Only 
location responses are routed on slot 2, whereas voice, text and ARS messages are routed using 
slot 1 (Home channel). The Enhanced GPS revert slot (slot 2) of all the repeaters and all 
subscribers in the system that send GPS data using the Enhanced GPS revert functionality should 
have the same window size. 

The total number of windows are shared among all the wide area Enhanced GPS revert repeaters 
in the system. Only one repeater in the system should have a value (90%, 75%, 60% or 45%) 
selected for Period Window Reservation (this does not have to be the Master repeater, a peer is 
also possible), whereas all the other repeaters in the system select a value of “None” using CPS. 
The repeater scheduler then schedule windows for all the other wide area enhanced GPS revert 
repeaters. 

The application server and control stations can be in the coverage area of any repeater in the IP 
Site Connect system. In Figure 3-31 below, they are shown to be in the coverage area of repeater 
1. For a window size of 5 or 6, it is recommended to use a network with an inter-repeater 
communication delay of 60 milliseconds or less. In case delay is observed to be higher than 60 
milliseconds, then a window size greater than 7 is recommended for system reliability even if the 
amount of data requires a smaller window size. 

NOTE: Increasing the window size decreases the system throughput. 

The user may also configure both slots of the wide area system for enhanced GPS revert. In this 
scenario, the user will need to configure both voice and other data on a different IP Site Connect 
system. 
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Figure 3-31 IP Site Connect System with an Enhanced GPS Revert Channel 



For details on data communication with applications through the repeater network interface 
instead of a control station, refer to the MOTOTRBO Network Interface Service (MNIS) and 
MOTOTRBO Device Discovery and Mobility Service (DDMS) sections. 
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3. 2. 3. 1.5. 3 Capacity Plus Mode 

In Capacity Plus mode, one or both slots of a Data Revert repeater can be configured as 
Enhanced GPS Revert channels. Text and server data are routed on the slot configured for Data 
Revert whereas GPS and ARS registration data is routed on the slot configured for Enhanced 
GPS Revert. The location requests are sent on the Trunked Channel while the location responses 
are sent on the Enhanced GPS Revert channel. 
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Figure 3-32 A Capacity Plus System with an Enhanced GPS Revert Channel 



For details on data communication with applications through the repeater network interface 
instead of a control station, refer to the MOTOTRBO Network Interface Service (MNIS) and 
MOTOTRBO Device Discovery and Mobility Service (DDMS) sections. 
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3.2.3. 1 .6 Summary of Features in Digital Repeater Mode 

The following features are supported in digital repeater mode: 
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*See “Scan Considerations” on page 76 for more information on the different scan modes 
supported by different topologies. 
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3 . 2 . 3. 2 Analog MOTOTRBO Radios in Repeater Mode 



TX = fi 
RX = f 2 



TX = f 2 RX = fi 
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Analog Repeater 
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Figure 3-33 MOTOTRBO Analog and Legacy Analog Radios on Legacy Analog Repeater 

MOTOTRBO radios supports analog repeater mode as well. In order for the MOTOTRBO radio to 
communicate with the existing analog or Dynamic Mixed Mode repeater, it must be programmed 
for analog mode as well as programmed with the same frequency and other options (PL, DPL, 
etc.) as the existing analog or Dynamic Mixed Mode repeater. While in analog mode, the 
MOTOTRBO radio supports most standard analog features including a subset of MDC signaling 
features. While in analog repeater mode, the MOTOTRBO radios will not support any of the digital 
features. While in Dynamic Mixed repeater mode, MOTOTRBO radios support both analog and 
digital features. 
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Figure 3-34 MOTOTRBO Analog and Legacy Analog Radios on MOTOTRBO Analog Repeater 

If required, the MOTOTRBO repeater can be programmed to operate in analog repeater mode. 
When operating in this mode, it interoperates with the existing analog radios as well as the 
MOTOTRBO radios operating in analog mode. It is important to note that the MOTOTRBO 
repeater can only be configured to operate in analog mode or digital mode. It does not do both at 
the same time. 



If required, the MOTOTRBO repeater can be programmed to operate in Dynamic Mixed Mode. 
When operating in this mode, repeater interoperates with the existing analog radios as well as the 
MOTOTRBO radios operating in analog and digital modes. Repeater dynamically switches 
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between analog and digital calls. While the repeater repeats one analog call at a time, it repeats 2 
digital calls at a time (one on each logical channel). 

The MOTOTRBO radio can be configured with both analog and digital repeater channels. The 
user can select between the analog and digital repeaters via the Channel Selector Knob. 

Alternatively, the MOTOTRBO radio user can program his radio to scan between the analog and 
digital channels to ensure that they do not miss a call. The programming can be done from the 
keypad of the radio or through CPS. Details of scan will be discussed in the following sections. 

Below is an example configuration of a mixed repeater mode system. 
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Figure 3-35 MOTOTRBO Digital Radios on a Two-Slot MOTOTRBO Digital Repeater with Analog Legacy 

Repeater Support 

3. 2. 3. 2.1 Summary of Features in Repeater Mode 

All features listed in “Analog Features” on page 167 are supported in analog repeater mode. 

3.2.4 IP Site Connect Mode 



In IP Site Connect mode, repeaters across dispersed locations exchange voice, data, and control 
packets over an IPv4-based backend network. The potential applications of this mode include: 

• Connecting two or more dispersed locations for day-to-day communications. 

For example, a customer’s manufacturing facility and a distribution facility across towns can 
be connected using MOTOTRBO repeaters in IP Site Connect mode. 
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• Building a larger or more effective RF coverage area. 

For example, multiple repeaters installed in an amusement park or a high-rise building can 
be connected to provide a contiguous area of RF coverage. The need for multiple repeaters 
may stem from any combination of geography (distance or topographical interference 
problems) and in-building or cross-building RF penetration issues. 

• Broadcasting announcements to all sites. 

This is useful in case of emergency or special events. 

• Connecting repeaters operating in different RF bands. 

For example, repeaters operating in UHF (UHF-1 and UHF-2) or VHF frequencies can be 
combined so that voice or data from one system flows into another. 

• Connecting to IP-based applications. 

IP Site Connect mode allows the customers to connect to third-party IP-based dispatch 
consoles, or call logging and recording applications, or routing calls to/from IP-based 
phones. 



3.2.4. 1 Topologies of IP Site Connect System 

3. 2. 4.1 .1 Wide Area System with Centralized Data Application Server 



This basic topology (as shown in Figure 3-36) is a single wide area system that consists of multiple 
single repeater systems operating in digital mode and zero or more Application Servers connected 
over a back-end network that supports IPv4, where: 



• A repeater system consists of a fixed digital repeater, digital radios (with or without an 
accessory or a data terminal), and two conventional physical channels. Only one of the 
repeaters, which is called the Master, has an additional role in the IP Site Connect mode. 
This additional role involves brokering of UDP/IP address and states of repeaters. 

• A radio uses one slot of a pair of frequencies (i.e. inbound and outbound) to communicate 
with its repeater. The pair of frequencies and/or the color code used by repeaters are not 
necessarily the same. Their frequencies may be in different frequency bands. The 
geographically adjacent repeaters have different frequencies. Two repeaters with the same 
frequency must be separated by a suitable distance to minimize interference and must use 
unique color codes. 

• An Application Server is a PC-like equipment where one or more application runs. An 
application can be a data application such as a Location Server, Text Message Server or a 
voice application such as a Console. An Application Server is connected to one or two 
Control Stations, and these Control Stations are connected over-the-air to a repeater. If the 
configuration has more than one Control Station, then the Application Server should have 
the MCDD software installed. A third-party application can reside on an Application Server 
and since the Application Server is connected to Control Stations (one per logical channel), 
the application is not required to implement any third-party API that partially emulates the 
behavior of a MOTOTRBO repeater and radio. 
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• The backend network can be a dedicated network or most probably an internet provided by 
an Internet Service Provider (ISP). ISPs provide a range of technologies such as dial-up, 
DSL (typically, ADSL), cable modem, broadband wireless access, ISDN, Frame Relay, 
Satellite Internet access, etc. The backend network cannot be based on a dial-up 
connection (due to small bandwidth) or Satellite Internet access (due to large delay). The IP 
Site Connect configuration does not require an ISP to provide a non-varying (static) IPv4 
address except for the Master repeater. A repeater can be behind a firewall and/or a router 
and/or a NAT. A repeater has USB and Ethernet network interfaces. The USB is used for 
connecting a local PC and Ethernet is used for connecting to the backend network of an IP 
Site Connect system. 




Figure 3-36 Wide Area System with Centralized Data Application Server 

For details on data communication with applications through the repeater network interface 
instead of a control station, refer to the MOTOTRBO Network Interface Service (MNIS) and 
MOTOTRBO Device Discovery and Mobility Service (DDMS) sections. 

There may be an application known as RDAC-IP running on a host PC connected to the backend 
network of an IP Site Connect system. The application displays the status of repeaters and allows 
its user to control some of the parameters of a repeater. The host PC maintains its link with the 
Master and other repeaters using the same protocols as other repeaters in an IP Site Connect 
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system. Note that there may be a local RDAC application running on a host PC connected to a 
repeater through RNDIS-USB interface. Also, analog, and local area only repeaters can be 
connected to wide area system so that they may be managed by the RDAC application. 

In digital mode, MOTOTRBO offers two logical channels. The configuration above shows both the 
channels acting as wide area channels. This means that when a call starts at one of the logical 
channels of a repeater, that repeater sends the call to all the other repeaters and they repeat the 
call on their corresponding logical channel. Since calls are not repeated on both logical channels, 
a radio on a logical channel cannot participate in a voice call on the other logical channel or logical 
channels of other IP Site Connect systems unless scan is utilized. Note that scanning cannot be 
enabled while roaming. Radio to radio data messages are not repeated on both slots either, 
although it is possible to support one Application Server to serve multiple wide area channels. The 
Application Server interfaces with the wide area channels in the same way as it interfaces with the 
local area channels. This is described in section 3. 2. 3. 1.3 “Server Based Data Applications in 
Repeater Mode”. 

3. 2.4. 1.2 Wide and Local Area Systems with Distributed Data Application 
Servers 

It is possible that one of the logical wide area channels of the repeaters is configured for local 
communication only. In this case, each site has its own logical channel for local communication. 
This is useful in case a customer need a significant load of local communication. This configuration 
offloads the local communication from the wide area channel. 

The following figure shows an example of such configuration in which one of the logical channels 
(say, slot 2) is used in IP Site Connect mode (wide area) and the other (slot 1) is used in digital 
repeater mode (local area). The calls originating on slot 1 are not sent to other repeaters. A 
customer should use slot 1 for local groups (i.e. groups whose members are expected to be 
present in the coverage area of the repeater); and slot 2 for groups whose members are 
distributed over the coverage area of multiple repeaters. 
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* WAC = Wide Area Channel 
*LC = Local Channel 
*TM = Text Messaging 



Figure 3-37 Wide and Local Area System with Distributed Data Application Servers 

For details on data communication with applications through the repeater network interface 
instead of a control station, refer to the MOTOTRBO Network Interface Service (MNIS) and 
MOTOTRBO Device Discovery and Mobility Service (DDMS) sections. 

The data messages sent over local channel 1 are not delivered to the Application Server 1 and 
therefore, if required, each geographical location should have their own Application Server with 
their own Presence Notifier. When a radio manually roams (i.e. changes dial positions) between a 
local area channel and a wide area channel, the radio registers with its respective Presence 
Notifier. To facilitate this, the radio ID of the control stations should be configured to be the same. 

If a customer requires more local capacity at a location then it is possible to add more repeaters 
working in Single-Site configuration and all the local slots of all the repeaters can share the same 
Application Server. In that case, the radios on the local channel will not be able to communicate 
with the wide area channels’ Application Server. 

3. 2.4. 1.3 Multiple Wide Area Systems with Centralized Data Application 
Server 

If a customer requires more wide area capacity, then it is possible to add another set of repeaters 
working in IP Site Connect mode. It is possible for the repeaters to share the same Application 
Server. This is shown in the figure below. In this case, the repeaters at a location may share the 
same link to the backend network. The bandwidth required for communication through the 
backend network should take this into consideration. See “Characteristics of Backend Network” on 
page 31 0 for further details. 
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Figure 3-38 Multiple Wide Area Systems with Centralized Data Application Server 

For details on data communication with applications through the repeater network interface 
instead of a control station, refer to the MOTOTRBO Network Interface Service (MNIS) and 
MOTOTRBO Device Discovery and Mobility Service (DDMS) sections. 

If a customer requires more wide area capacity for location data, then it is possible to use one or 
more wide area channels as GPS Revert Channels. The GPS Revert Channel behavior of radios 
in IP Site Connect mode is the same as the radios behavior in digital repeater mode with the 
exception that the GPS is sent unconfirmed on a wide area channel. See “GPS Revert in Repeater 
Mode” on page 240 
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3.2.4. 1 .4 Network Topologies for IP Site Connect 

The IP Site Connect topologies described in the previous sections can reside on a range of 
backend network configurations and technologies. Logical connections between the wide area 
channels can all reside on the same physical network. The actual network topology chosen will 
most likely be driven by the repeater’s physical location and the network connectivity available at 
that location. The Network Topologies can be broken up into two basic configurations: 

• Local Area Network Configuration 

• Wide Area Network Configuration 

But note that most network topologies will be a combination of both Local and Wide Area network 
configurations. Each individual configuration will be described and discussed. 

Note that the same network configurations can be used for Digital or Analog Repeaters, Enabled 
or Disabled Repeaters, Wide Area or Local Area Repeaters, RDAC-IP, or any other third-party 
device that utilizes the IP Site Connect link establishment protocol. 

3. 2.4. 1.4.1 Local Area Network (LAN) Configuration 

Customers that have high capacity network connectivity throughout their organization will most 
likely have a desire to utilize their existing network for wide area connectivity. IP Site Connect 
supports the following technologies: 

• Private LANs 

• Corporate LANs 

• Private Wireless Systems 

Exact configurations of Local Area Networks can vary greatly. As long as the devices are on the 
same network, or have access to other networks through an internal router or NAT configurations, 
the IP Site Connect system will operate correctly. It is also assumed that in these local 
configurations that bandwidth is not an issue. Nevertheless, it is important for the system installer 
to understand the bandwidth that each IP Site Connect devices require in order to operate 
optimally. See “Network Bandwidth Considerations” on page 312 

The diagram below shows a simple diagram of IP Site Connect devices located at different sites 
connected through a local area network. Note that in this drawing the IP Site Connect devices 
could be in one or more Wide Area Systems (i.e. more than one Master), could contain local area 
channels or even be an analog repeater, a disabled repeater, or RDAC IP application. 

Only the repeaters acting as Masters will require a local static IPv4 address. The other IP Site 
Connect devices will utilize this local static IPv4 address to establish their link with the wide area 
system. 





System Components and Topologies 



255 




Figure 3-39 IP Site Connect devices connected through Local Area Network 

3. 2.4. 1.4. 2 Wide Area Network Configuration 

The largest benefit of IP Site Connect is the ability to connect sites over public Internet Service 
Provider (ISP) links as well as private high speed connections. ISPs provide a range of 
technologies with varying bandwidth. IP Site Connect supports the following technologies (as long 
as the requirements listed in the backend Network Considerations section are met): 

• Private T 1 

• DSL (typically ADSL) 

• Cable Modem 

• Broadband Wireless Access (e.g. Public Canopy provided by WISPs [Wireless Internet 
Service Providers]) 

• ISDN 

• Frame Relay 









256 



System Components and Topologies 



IP Site Connect does not support dial-up connections (due to small bandwidth) or Satellite Internet 
access (due to large delay). When utilizing public internet connections, it is important that the 
system installer understand the bandwidth and delay that each IP Site Connect device requires in 
order to operate optimally. They must also understand the details (bandwidth and delay) of the 
network link at each site and between sites. For example, if connecting sites have long distances 
between them, the delay of the entire link needs to be considered. Spanning continents connected 
via Satellite may introduce unacceptable delay. But, if the continents are connected via fiber optic 
there may not be any issues. 

Also keep in mind that because traffic from one repeater is sent to every repeater, the required 
bandwidth of the ISP link at one site is a function of the amount of other repeaters in the system. 
Adding a repeater will increase the required bandwidth at all sites. See “Network Bandwidth 
Considerations” on page 312 

A repeater can be (and is suggested to be) behind a router and/or a NAT and/or a firewall. 
Although not required, it is highly suggested in order to protect against the undesired solicitations 
common over the public internet. Although IP Site Connect will work through most off-the-shelf 
devices, the following router/NAT/firewalls are therefore suggested for use. 

• HP - MSR 20-20 (supports “hair-pinning”) 

• D-Link - EBR-2310 

• CISCO - ASA-5505 (supports “hair-pinning”) 

As previously described, peer-to-peer communications over the network can be optionally 
authenticated and are also encrypted end-to-end if enabled in the radios. If this is not considered 
sufficient for a particular customer, IP Site Connect supports the ability to work through a Secure 
VPN (Virtual Private Network). Secure VPN is not a function of the IP Site Connect device but 
rather of the router. It is important to note that VPN does add the need for additional bandwidth and 
may introduce additional delay. This should be taken into consideration in bandwidth planning. The 
following Secure VPN router is suggested for use. See “Network Bandwidth Considerations” on 
page 312 

• Linksys 4 Port Gigabit Security Router with VPN: Model RVS4000. 

Only the repeaters acting as Masters require a publicly accessible static IPv4 address from the 
Internet Service Provider. The other IP Site Connect devices utilize this publicly accessible static 
IPv4 address to establish their link with the wide area system. In addition, the router/NAT/firewall 
connected to the Master require some configuration (open port) so that unsolicited messages from 
other repeaters can reach the Master repeater. 

The diagram below shows a simple diagram of IP Site Connect devices located at different sites 
connected through a wide area network. 
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Note that in this drawing the IP Site Connect devices could be in one or more Wide Area Systems 
(i.e. more than one Master), could contain local area channels or even be an analog repeater, a 
disabled repeater, or RDAC IP application. 




Figure 3-40 IP Site Connect Devices connected through Wide Area Network 

3. 2.4. 1.5 Wide and Local Area Network Configuration 

Most network topologies are a combination of both Local and Wide Area network configurations. 
For example, there may be a need to link two or more sites with existing local networks together 
over a public ISP, or maybe link one or more remote mountain RF site into a corporate network. 
When doing this, there are a few extra precautions to consider that are not covered in the previous 
sections. 

The number of IP Site Connect devices connected together behind a single wide area connection 
(i.e. behind one router) can have a large effect on the required bandwidth of the wide area link. 
The bandwidth requirements of a wide area link are the summation of the bandwidth requirements 
of all IP devices behind the router. In other words, if there are three IP Site Connect devices 
utilizing a single ISP link, it must have enough bandwidth to support all three. Recall that the traffic 
from one repeater is sent to every repeater; therefore the required bandwidth of the ISP link at one 
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site is a function of the amount of other sites in the system. Adding a repeater at one site increases 
the required bandwidth at all sites. 

Similar to the Wide Area Network configurations, the repeaters acting as the Master will require a 
publicly accessible static IPv4 address from the Internet Service Provider. The other IP Site 
Connect devices utilize this publicly accessible static IPv4 address to establish their link with the 
wide area system, not a local IPv4 address. This is true even for the IP Site Connect devices that 
are located on the same Local Area Network as the Master. 

Again, similar to the Wide Area Network configurations, the router/NAT/firewall connected to the 
Master require some configuration (open port) so that unsolicited messages from other repeaters 
can reach the Master repeater. 

To support the ability for the IP Site Connect devices to communicate to other devices on its LAN 
using the WAN IPv4 address, the routers on those WANs must support a feature referred to as 
“hair-pinning”. Hair-pinning is returning a message in the direction it came from as a way for it to 
reach its final destination. This is per the router standard RFC 4787. 

The diagram below shows a simple diagram of IP Site Connect devices located at different sites 
connected through a mix of local and wide area networks. Note that in this drawing the IP Site 
Connect devices could be in one or more Wide Area Systems (i.e. more than one Master), could 
contain local area channels or even be an analog repeater, a disabled repeater, or RDAC IP 
application. 




Figure 3-41 IP Site Connect Devices connected through Local Area and Wide Area Network 
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3.2.4. 1 .6 Summary of Features in IP Site Connect Mode 



The following features are supported in IP Site Connect mode: 



Digital MOTOTRBO Radios in IP Site Connect Mode 


Voice 

Features 


Signaling 

Features 


Emergency 

Handling 


Data Calls 


Other Features 


Group Call 


PTT ID and 
Aliasing 


Emergency 

Alarm 


Text 

Messaging 


Two Wide Area 
Channels (slot 
1 and slot 2) 


Remote 
Diagnosis and 
Control 


Private 

Call 


Radio Inhibit 


Emergency 
Alarm and Call 


Location 

Tracking 


Mix of Wide 
Area and Local 
Area Channels 


Roaming 


All Call 


Remote 

Monitor 


Emergency 
Alarm with Voice 
to Follow 


Telemetry 


Scan* 


Wide Area 
Coverage 


Dual Tone 
Multi 

Frequency 


Radio Check 


Emergency 
Revert Per Site 


Third-Party 

(ADP) 

Applications 


Polite to All 

System 

Access 


Time-out Timer 


Voice 

Interrupt 


Call Alert 


Emergency 
Voice Interrupt 


GPS Revert 
Per Site 


Polite to Own 
System 
Channel 
Access 


Privacy 


Digital 

Telephone 

Patch 


Remote Voice 
Dekey 




Data Over 

Voice 

Interrupt 


Impolite 

Channel 

Access 





* See “Scan Considerations” on page 76 for more information on the different scan modes supported 
by different topologies. 

The following chapter discusses some of the considerations to take while designing a 
MOTOTRBO system. It focuses more on how the user uses the system, and the configuration 
needed to support it. Although a basic system topology may already have been chosen, the next 
chapter helps dig deeper into how the end user utilizes the system, and therefore gives additional 
ideas on how it should be configured. 
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3.2.5 Capacity Plus Mode 



Prior to R02.30.00, Capacity Plus allows up to six trunked repeaters (12 logical channels) and 
twelve Data Revert repeaters (24 logical channels). For the system to operate properly, all the 
repeaters must have the same software version. From software version R02.30.00 onwards, up to 
eight Trunked Repeaters (16 logical channels) and twelve Data Revert Repeaters (24 logical 
channels) are allowed. The Rest Channel IP address must be configured using a valid subnet IP 
address where the system resides, and cannot be left as 0.0. 0.0. 

In Capacity Plus mode, all the radios share the channels of all the trunked repeater(s). The 
probability of all channels being busy at the same instant is low. Hence, radio finds less blocking of 
calls compared to when only one channel is available to the radio. Similarly, for the same quality of 
service, sharing of channels allows more calls and thus increases channel capacity. 

In Capacity Plus, a channel is configured either for trunking or for data revert. A radio has a list of 
all Trunked Channels and a list of Data Revert Channels. While configuring channels, observe the 
following rules: 



• Both channels of a repeater should be used for the same purpose. This implies that if one 
channel of a repeater is a Trunked Channel, then the other channel is also a Trunked 
Channel. Similarly, if one channel of a repeater is a Data Revert Channel, then the other 
channel is also a Data Revert Channel. 

• The CPS provides a zone for keeping all the trunked and Data Revert Channels. The zone 
is called “Channel Pool”. All the trunked and Data Revert Channels should be kept in the 
“Channel Pool”. 



3.2.5. 1 Topologies of Capacity Plus System 

3. 2. 5.1 .1 A System with No Data Application Server and Local RDAC 



This configuration is the most basic of the Capacity Plus topologies. It does not support a remote 
RDAC or data messages to or from a Server. 

One of the repeaters has an additional role of “Master”; a broker for discovering repeaters. The 
Master has a static address (i.e. IPv4 address and UDP port number), which is configured in all the 
repeaters and RDAC. Static address is an address that does not change with time. If the address 
of the Master changes, then all the repeaters and RDAC must be reconfigured with the new 
address. 





System Components and Topologies 



261 




Figure 3-42 Capacity Plus Devices with Local RDAC and no Data Application Server 

A minimal configuration of the above figure can have just one repeater without RDAC. In this case, 
the system behaves as a two-channel trunked system. 




Figure 3-43 Two-channel Capacity Plus System without Data Application Server 

3. 2. 5. 1.2 A System with No Data Application Server and Remote RDAC 



If RDAC is on a different IPv4 network, then the backend network of Capacity Plus should be 
connected to the external IP network using a router. In this case, use the static address of the 
Master, as seen from the other side of the router, to configure the repeaters and RDAC. Note that 
the router may be required to do port-based network address translation for each repeater. Prior to 
software version R02.20.12, the router should support “hair-pinning” and have sufficient bandwidth 
to handle all the messages between repeaters. Hair-pinning is returning a message in the direction 
it came from as a way for it to reach its final destination. This is per the router standard RFC 4787. 
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In software version R02.20.12 or later, Capacity Plus can work with, or without hair-pinning 
capabilities in the router. When a non-hair-pinning router is utilized, each repeater must be 
configured with a unique static IP address and a unique UDP port. The Rest Channel IP address 
must also be configured as a unique static IP address and a unique UDP port. The router must be 
configured to “no port address translation/port preservation for UDP” if a non-hair-pinning router is 
utilized. 



su 



su 





Figure 3-44 Capacity Plus Devices with Remote RDAC and no Data Application Server 



3.2.5. 1 .3 A System with Data Application Server on Trunked Channels 



It is possible to send data messages to a Data Server over the Trunked Channels. This is 
recommended for a system that requires sending limited number of data messages to the Server. 
This configuration requires one or more Trunked Control Stations. The Server must not have the 
MCDD installed. 

If there is more than one Trunked Control Station, the configuration should adhere to the following 
rules: 

1 . The maximum number of Trunked Control Stations should not be more than the number of 
Trunked Channels. 

2. To achieve a success rate of 90%, the number of data messages per minute per Trunked 
Control Station, should be less than 10. It is assumed here, that the payload of a data 
message is 50 bytes or characters long. 

3. The IDs of all Trunked Control Stations should be different. 

4. The radios should be grouped into ‘n’ sets, where ‘n’ is the number of Trunked Control 
Stations. 
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5. Each set of radios is associated to a Trunked Control Station. This implies that the 
configured IP address of the server in a radio is the IP address of its Trunked Control 
Station’s peripheral. 

6. For each set of radios, it is required to make one or more entries in the IP Routing Table of 
the Application Server such that a data packet transmitted to a radio is routed to the port of 
the Trunked Control Station associated with the set of the radio. 




( 4(4 





Figure 3-45 Capacity Plus Devices with Data over Trunked Channels 



A minimal configuration of Figure 3-45 is shown in Figure 3-46 below: 
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Figure 3-46 Two-channel Capacity Plus Devices with Data over Trunked Channels 
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3.2.5. 1 .4 A System with Data Application Server on Revert Channels 

If a system requires sending a large number of data messages (e.g. location data) to a Server, 
Capacity Plus is able to dedicate up to a maximum of twelve repeaters for the transmission to take 
place. This configuration requires one Revert Control Station per Data Revert Channel (i.e. slot) 
and at least one Trunked Control Station. The IDs (and therefore the IPv4 address) of all Revert 
and Trunked Control Stations are the same. The IPv4 address of the Server (as seen by a radio) is 
derived from the SUID of the Control Stations. 

The Server sends data packets to the radios via Trunked Control Stations, and not via the Revert 
Control Stations. As the data packets are not sent via the revert channels, there is no need for 
installation of the MCDD (Multi-Channel Device Driver) software in the Server. 

A Capacity Plus system can have more than one Trunked Control Station. Therefore, it is required 
to distribute the data packets fairly among the Trunked Control Stations and the distribution should 
be transparent to the applications in the Application Server. A simple way to achieve fair 
distribution is to group the radios into ‘n’ sets, where ‘n’ is the number of Trunked Control Stations 
and associate each set to a Trunked Control Station. For each set of radios, it is required to make 
one or more entries in the IP Routing Table of the Application Server so that a data packet 
transmitted to a radio is routed to the port of the Trunked Control Station associated with the radio. 
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Figure 3-47 Capacity Plus Devices with Data over Revert Channels 
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3. 2. 5. 1.4.1 A System with a Dispatch Station (Console) 

A dispatch station can be connected to a Capacity Plus system using one or more Trunked Control 
Stations. The interface between the dispatch station and the Trunked Control Stations can either 
be 4-wire or XCMP/USB. The dispatch station could either be a single position console, or a 
multiple position server-based system. 

The number of Trunked Control Stations depends on the number of concurrent paths supported by 
the dispatch station. A simple configuration will have one Trunked Control Station dedicated to 
each group. The dispatch station maintains the association between the group and the Trunked 
Control Station. To make a call to a group, the dispatch station uses the Trunked Control Station 
associated within the group. The configuration may have a Trunked Control Station dedicated to a 
Private Call. All the radios have this Trunked Control Station listed in their address book as a 
dispatcher. 

If the configuration has data applications, then the Trunked Control Stations for both data and 
dispatch station should be mutually exclusive. This means that a Trunked Control Station should 
not be used for both data and voice. The configuration is shown in the following figure. 
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Figure 3-48 Capacity Plus Devices with a Dispatch Station (Console) 
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For details on data communication with applications through the repeater network interface 
instead of a control station, refer to the MOTOTRBO Network Interface Service (MNIS) and 
MOTOTRBO Device Discovery and Mobility Service (DDMS) sections. 

3.2.6 Linked Capacity Plus (LCP) Mode 

Prior to software version R02.20.12, Linked Capacity Plus allows up to 15 sites in a system when 
maximum Trunked Repeaters (at a site) are less than, or equal to three. Alternatively, Linked 
Capacity Plus allows up to six Trunked Repeaters (12 logical channels) when the number of sites 
are less than or equal to three. Each LCP site can have up to 3 Data Revert repeaters (6 logical 
channels) per site. From software version R02.20.12 onwards, LCP allows up to 15 sites in a 
system with a maximum of eight Trunked Repeaters (16 logical channels) at a site. For the Data 
Revert Repeaters at a site, up to eleven Revert Repeaters (22 logical channels) can be supported. 
However, the number of Trunked Repeaters plus the number of Data Revert Repeaters must not 
exceed a total of 12. For example, if there are eight Trunked Repeaters at a site, only up to four 
Data Revert Repeaters can be supported at that site. 

It is not a requirement to have the same number of repeaters at each site but all the repeaters at 
the same site must have the same software version. A Linked Capacity Plus system supports local 
calls (that is, a local call is received by radios at only one site) and the number of repeaters at a 
site is a function of the expected volume of the local calls. Additionally, due to co-channel 
interference or failure of repeaters, the number of available repeaters may be different at different 
sites. 

All repeaters at a site must be on the same LAN, in other words, they must be behind the same 
router and plugged into the same network switch. It is strongly recommended that no other device 
be present on the LAN. For LCP software versions R02. 10.00 and prior, the router at the Master 
repeater’s site should be capable of hair-pinning, to ensure that the firewall is open to limited UDP 
and IP addresses. In software versions R02.20.00 and later, LCP can work with, or without hair- 
pinning capabilities in the router at the Master repeater’s site. When a non-hair-pinning router is 
utilized, each LCP repeater at the Master repeater’s site must be configured with a unique static IP 
address and a unique UDP port. The Rest Channel/Site IP address must also be configured as a 
unique static IP address and a unique UDP port for the site. If a non-hair-pinning router is utilized, 
the router must be configured to “no port address translation/port preservation for UDP”. 

For an advanced security, a router with VPN capabilities can be selected. However, a VPN router 
requires at least 50% more ISP bandwidth than a non-VPN router. Thus, appropriate trade-offs 
need to be considered between the ISP bandwidth and the desired level of system security. A 
secure router usually contains firewall, network address translation, and encryption capabilities. 
The LCP system supports operation over both secure and non-secure modes of the router. 

Only repeaters with 32 MB of internal memory (e.g. XPR 8380/XPR 8400 or MTR3000) can 
support the LCP configuration. Like an IP Site Connect conventional system, every LCP system 
needs one repeater to act as the Master. The Master repeater has a static IP address, while other 
repeaters have static IP addresses or obtain them dynamically from the ISP. All the repeaters in 
the LCP configuration register with the Master using the static IP address of the Master. The LCP 
system may have many repeater applications like the RDAC and MNIS that are considered as 
repeaters by the Master repeater. However, satellite receivers are not treated as repeaters. When 
the number of repeaters and these applications in a system exceeds 140, a dedicated Master 
repeater must be deployed in the system. This dedicated Master should be added to a site as a 
Data Revert repeater, but adding it does not reduce the number of Data Revert repeaters that can 
be normally deployed at that site. This dedicated Master repeater should have no RF-related 
activities such as CWID and OTA receiving/transmitting. 
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In LCP, a channel is configured either for trunking or for data revert. But both channels of a 
repeater should be used for the same purpose. This implies that if one channel of a repeater is a 
Trunked Channel, then the other channel is also a Trunked Channel. Similarly, if one channel of a 
repeater is a Data Revert Channel, then the other channel is also a Data Revert Channel. In LCP, 
a Data Revert Channel can be configured either as a local Data Revert Channel, or as a wide area 
Data Revert Channel. 

A Data Revert Channel could be either an Enhanced GPS Revert Channel or a normal Data 
Revert Channel. Each logical channel of a Data Revert Repeater can be independently configured 
either as an Enhanced GPS Revert Channel or as a normal Data Revert Channel. A radio has a 
list of all Trunked Channels and a list of Data Revert Channels for each site. 

Linked Capacity Plus can be deployed for various system topologies. The following section defines 
some of the key topologies. 
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3.2.6. 1 Topologies of Linked Capacity Plus System 

3. 2. 6.1 .1 A Linked Capacity Plus System with Data over Trunked Channels 
(optional) 



Figure 3-49 shows a basic LCP system having three sites. Site 1 and 2 has four trunked repeaters 
and site 3 has three trunked repeaters. The number of repeaters at each site need not be the 
same. In this configuration, all the repeaters are configured for trunked mode of operation - there is 
no Data Revert Repeater. One of the repeaters has an additional role of “Master”; a broker for 
discovering repeaters. The Master has a static address (IPv4 address and UDP port number), 
which is configured in all the repeaters. If the address of the Master changes, then all the 
repeaters must be reconfigured with the new address. 




Figure 3-49 A Linked Capacity Plus System with Data over Trunked Channels 

It is possible to send data messages to a Data Server over the Trunked Channels. This is 
recommended for a system that requires sending limited number of data messages to the server. If 
the data has to be sent to and from the server, then one Conventional Control Station per Trunked 
Channel and one or more Trunked Control Stations need to be added at a site in the basic 
topology. In this configuration, all the repeaters are configured for trunked mode of operation, 
where there is no Revert repeater. For this topology, the radio does not require a Revert channel 
list. The Trunked Control Stations are configured with no talkgroups and therefore ignore the calls 
received over-the-air. A Trunked Control Station follows the Rest Channel and when requested by 
a PC server, transmits the message sent by the server. 

If there is more than one Trunked Control Station, the configuration should adhere to the following 
rules: 
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1. The maximum number of Trunked Control Stations should not exceed the number of the 
Trunked Channels. 

2. To achieve a success rate of 90%, the number of data messages per minute per Trunked 
Control Station, should be less than 10. It is assumed here, that the payload of a data 
message is 50 bytes or characters long. 

3. The IDs of all Trunked Control Stations should be different. 

4. The radios should be grouped into ‘n’ sets, where ‘n’ is the number of Trunked Control 
Stations. 

5. Each set of radios is associated to a Trunked Control Station. This implies that the 
configured IP address of the server in a radio is the IP address of its Trunked Control 
Station’s peripheral. 

6. For each set of radios, it is required to make one or more entries in the IP Routing Table of 
the Application Server such that a data packet transmitted to a radio is routed to the port of 
the Trunked Control Station associated with the set of the radio. 

For group data that needs to be sent to multiple sites, the data talkgroup needs to be a wide-area. 
For data to be sent to the server, the data can be sent as an individual data call. Individual data 
calls engage only the source and destination sites of the call. 

Like Capacity Plus, LCP requires Trunked Control Stations for data from a server to the radio. The 
Trunked Control Stations must be upgraded with LCP software. The Trunked Control Stations 
sending the server data as an application layer acknowledgement, shall delay the 
acknowledgement, by 420-480 ms, for a reliable reception by a radio. If more than one Trunked 
Control Stations are connected in the system, then the acknowledgement is sent based on the 
routing table in the server PC. 

NOTE: The server PC cannot access the repeater interface, only the radio interface. 

This topology is recommended when there are less RF frequencies for communication and where 
data calls are less frequent compared to voice calls. This topology is also preferable for small data 
throughput. The following LCP topology with a dedicated revert repeater provides higher data 
throughput. 

A minimal variation of this configuration can have only one repeater per site. In this scenario, the 
LCP system is similar to an IP Site Connect system with the following differences. The minimal 
LCP system provides: 

• Faster automatic roaming compared to an IP Site Connect system 

• Additional SAT time of approximately 180 ms 

• Reduced battery life by 45-60 minutes compared to an IP Site Connect system 

• Higher call handling capacity because the system: 

• Works as a two-slot trunked system 

• Can have local talkgroups 

• Uses at most two sites for Private Calls 

• Uses statically associating sites for wide-area talkgroups 

Another minimal variation of this configuration consists of only one site. In this case, the LCP 
system is similar to a Capacity Plus system. 
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3. 2. 6. 1.2 Linked Capacity Plus with Data over Local Revert Channels 

For a higher data throughput, the preferred configuration is to have channels dedicated for data 
only. Such channels are defined as Data Revert Channels. In a Revert repeater configuration, a 
Revert repeater is connected in local mode. Whenever a radio has to send data to the server, it 
switches to one of the revert channels in the revert channel list and transmits data on the revert 
channel. The conventional control station listening to each revert channel of the Revert repeater 
receives the data and sends it to the connected PC. The PC at each site routes the data to the 
server PC, hence only one server PC can manage the radios at different sites. A PC at each site 
routes the data to the server PC based upon its prior routing configuration. 

Similar to Capacity Plus, in LCP, the server uses Trunked Control Stations to send the messages 
to a radio. To simplify the system topology, the Trunked Control Station needs to be present at one 
site only. 

This system configuration can also be used with Enhanced GPS mode of the revert repeater. The 
overall revert topology remains the same. 
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Figure 3-50 A Linked Capacity Plus System with Data over Local Revert Channels 
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3.2.6. 1 .3 Linked Capacity Plus with Data over Wide Area Revert Channels 

This topology is similar to the previous, except that the revert repeaters are connected in a wide- 
area mode. This topology requires fewer control stations compared to the previous topology, since 
the revert repeaters are connected in a wide-area mode configuration. This topology also supports 
wide area mode of an Enhanced GPS Revert repeater. This topology requires the same number of 
revert repeater channels at each site. 

The revert data call capacity of this configuration is ‘n’ times less than the configuration in the 
previous topology, where ‘n’ is the number of sites. The other configuration details for this topology 
are identical to the previous topology. 

It is possible to combine topology 2 and 3. In a combined topology, some revert channels could be 
wide-area channels, and some local. 

For example, radios in the wide-area talkgroup personality can use the wide-area revert channels 
while the radios using local communication can use the local area revert channels. 

LAN IP Network 

Site 1 / ~ " =■ * __ __ Site 2 Site 3 




Figure 3-51 A Linked Capacity Plus System with Data over Wide Area Revert Channels 

For details on data communication with applications through the repeater network interface 
instead of a control station, refer to the MOTOTRBO Network Interface Service (MNIS) and 
MOTOTRBO Device Discovery and Mobility Service (DDMS) sections. 
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3. 2. 6. 1.4 Summary of Features in Capacity Plus and Linked Capacity Plus 
Modes 



The following features are supported in Capacity Plus and Linked Capacity Plus modes: 
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The following chapter discusses some of the considerations to take while designing a 
MOTOTRBO system. It focuses more on how the user uses the system, and the configuration 
needed to support it. Although a basic system topology may already have been chosen, the next 
chapter helps dig deeper into how the end user utilizes the system, and therefore gives additional 
ideas on how it should be configured. 

3.2.7 Digital Voting 

Digital voting is available in the following system configurations: 

• Digital Conventional Single Site 

• IP Site Connect (IPSC) 

• Capacity Plus 

• Linked Capacity Plus (LCP) 



When installing a receiver site (that may contain multiple receivers for Capacity Plus or LCP 
system) in any of the system configurations, the receiver site must not be in the same LAN that the 
voter site is in. 
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In order for the voting functionality to be working properly, the one way network delay between the 
repeater and any of its receivers must be less or equal to 40 milliseconds. Additionally, the network 
asymmetry between the repeater and any of its receivers must be less or equal to 12 milliseconds. 
The network asymmetry is the absolute value of the time difference for an IP packet to travel from 
the repeater to the receiver, and from the receiver to the repeater. This applies to all system 
configurations. Since the distance between the repeater and receiver is normally less or equal to 
90 miles (approximately 145 kilometers), most of the business grade IP networks are able to meet 
this 40 milliseconds per 12 milliseconds network requirement. 

3.2.7. 1 Digital Voting in Digital Conventional Single Site/Local Channels 

In a voting configuration for Conventional Single Site system or for local channels, one voting 
repeater may be deployed with none, or up to eight (8) satellite receivers. If RDAC, MNIS and 
other repeater peer applications are present in the system, a general rule applies - for every 4 
RDACs or data applications, the maximum number of satellite receivers are reduced by 1; for 
every 2 voice applications, the maximum number of satellite receivers are reduced by 1 . 

The satellite receivers receive the radio’s transmission, verify and forward it to the voting repeater 
over an IP based network. The voting repeater then selects the best copy of the radio’s 
transmission and repeats it over the air. This not only extends the repeater’s inbound range, but 
also improves the inbound signal quality. 

The following diagram shows a Conventional Single Site system with four satellite receivers. 
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Figure 3-52 Digital Voting Topology for Conventional Single Site or IP Site Connect Local Channel 
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3. 2. 7. 2 Digital Voting in IP Site Connect (Wide Area Channels) 

In a voting configuration for IPSC, each site can have none or a few satellite receivers. It is not 
necessary for the number of satellite receivers to be the same at each site. The following diagram 
shows the topology of a two-site IPSC voting system with each site having four satellite receivers. 
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Figure 3-53 Digital Voting Topology for a Two-Site IP Site Connect System 



The maximum number of satellite receivers for a specific voting repeater depends on the number 
of repeater sites and RDAC/MNIS. The following table shows the maximum number of satellite 
receivers supported per voting repeater in a multi-site system. 
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Number of Sites 


Maximum Number of Satellite Receivers Supported 
Per Voting Repeater 3 
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a. In general, for every four RDACs or data applications included in the system, the maximum 
number of satellite receivers is reduced by one. For every voice application included in the system, 
voice console, for example, the maximum number is reduced by two. 



3 . 2 . 7. 3 Digital Voting in Capacity Plus 

In a Capacity Plus voting configuration, the maximum number of satellite receivers supported for a 
RF channel is eight (8). If RDAC, MNIS and other repeater peer applications are in the system, in 
general, for every four (4) RDACs or data applications, the maximum number of satellite receivers 
are reduced by one (1). For every two (2) voice applications, the maximum number of satellite 
receivers are reduced by one (1). 

In order to obtain the same Trunked Channel inbound/outbound coverage from channel to 
channel, each Trunked RF Channel requires a satellite receiver at any selected satellite receiver 
location. Hence, each Trunked RF Channel requires the same number of satellite receivers 
altogether. It is recommended to place a satellite receiver for each Data Revert RF Channel to 
achieve the same inbound/outbound coverage as the voice channels. However, this is not a 
requirement. 

Figure 3-54 shows the voting topology for Capacity Plus with two (2) RF channels, where each 
channel has four (4) satellite receivers. 
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Figure 3-54 Digital Voting Topology for a Capacity Plus System 
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3. 2. 7.4 Digital Voting in Linked Capacity Plus 

The voting configuration in LCP is a combination of the IPSC and Capacity Plus voting 
configurations. Each site can have none or a few satellite receivers. 

For each LCP site, similar to Capacity Plus, in order to obtain the same Trunked Channel inbound/ 
outbound coverage from channel to channel, each Trunked RF Channel requires a satellite 
receiver at any selected satellite receiver location. Hence, each Trunked RF Channel requires the 
same number of satellite receivers altogether. It is recommended to place a satellite receiver for 
each Data Revert RF Channel to achieve the same inbound/outbound coverage as the voice 
channels. However, this is not a requirement. It is not necessary for the number of satellite 
receivers to be the same at different LCP sites. 

Figure 3-55 shows the topology of a two-site LCP voting system with a RF channel at a site having 
four (4) satellite receivers. The maximum number of satellite receivers supported at a site for a RF 
channel depends on the number of repeater sites and RDAC/MNIS. 
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Figure 3-55 Digital Voting Topology for a Two-Site Linked Capacity Plus System 
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SECTION 4 SYSTEM DESIGN CONSIDERATIONS 



4.1 Purpose 

This section describes various system configurations readers need to know before deciding how to 
best support the needs and usage of their customers. It explains the usage supported on a single 
repeater system, as a guideline for design. It then identifies the customer needs that need to be 
considered when optimizing system performance. It continues to cover various other 
considerations that may need to be addressed during the design phase. 

4.2 Analog to Digital Migration Plans 

System Migration is the process of moving from one operating platform to another. The following 
sections elaborate system migration from an analog two-way radio platform to a digital two-way 
radio platform. 

4.2.1 Pre-Deployment System Integration 

Where applicable, the dealer should perform system assembly, configuration, adjustment, and 
brief testing of the MOTOTRBO system. Each component contains documentation necessary for 
system installation and optimization. The benefits of staging a system in a controlled environment 
include: 



• Equipment accountability in preparation for system assembly 

• System assembly and programming in a controlled test environment 

• Documentation of programming information 

• Fabrication of cables and connectors 

• Test of complete functionality and initial level-setting for system optimization 
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4.2.2 Analog to Digital Preparation and Migration 

A Dynamic Mixed Mode repeater does not enable communication between legacy analog and 
MOTOTRBO digital radios operating in digital mode. When the repeater receives an analog call, it 
retransmits in analog mode. When the repeater receives a digital call, it retransmits in digital mode. 
It is the scanning feature in the subscriber that allows the MOTOTRBO radios, programmed with 
both analog and digital channels, to listen to analog calls from legacy analog radios. While the 
MOTOTRBO radio is listening to an analog call through PL scanning, it talks back in analog mode, 
if keyed up within the call hang time. 

NOTE: The MOTOTRBO radio needs to be in analog mode to initiate or return an analog call with 
legacy analog radios. 

This section details migration strategies which involve gradually replacing existing analog radios 
with MOTOTRBO radios. 

1. To migrate a system with a single non-MOTOTRBO repeater channel, radio users are 
encouraged to use MOTOTRBO radios in digital direct mode/dual capacity direct mode. 
This gives them an opportunity to familiarize themselves with the MOTOTRBO digital 
feature set, while communicating with legacy analog radios through the legacy analog 
repeater. If the analog system does not use any PL/DPL encoding, then analog radios will 
hear noise caused by digital radio transmissions communicating in direct mode/dual 
capacity direct mode. 

Over time, as the number of MOTOTRBO radios increases, a cut-over day is pre- 
determined. On that day, the legacy analog repeater will be replaced by a MOTOTRBO 
digital repeater. Radio users communicate with each other in Talkaround while the new 
repeater is being installed. Once the MOTOTRBO repeater is operational, MOTOTRBO 
radio users switch to digital repeater mode, while legacy analog radio users communicate 
in Talkaround. 

2. To migrate a system with two repeater channels, MOTOTRBO radios are programmed 
with both the current analog channels as well as future digital channels. A recommended 
approach is to place all the analog channels in one ‘zone’, and all digital channels in 
another ‘zone’. Analog and digital channels are programmed into the MOTOTRBO radios 
to allow users to communicate on both repeaters. Scan Lists are configured to allow users 
to monitor both analog and digital voice transmissions. 

Both the existing analog repeater and the MOTOTRBO repeater (in digital mode) should 
be set-up to operate side-by-side. This configuration requires two frequency pairs: one 
pair for the analog repeater and one pair for the MOTOTRBO repeater. Users gradually 
migrate over to the MOTOTRBO repeater (i.e. legacy analog radios are swapped for 
MOTOTRBO radios). Once every analog radio has been swapped with a MOTOTRBO 
radio, the legacy analog repeater can be replaced with another MOTOTRBO digital 
repeater. The system is now fully digital with two digital repeater channels. 

3. To migrate a system with a single MOTOTRBO repeater channel, load/upgrade the 
MOTOTRBO repeater with firmware version R01.06.10 or later. Configure the repeater to 
Dynamic Mixed Mode using the CPS. This configuration requires one frequency pair. 
Analog and digital channels are programmed into the MOTOTRBO radios to allow users 
to communicate through the same repeater. Scan Lists are configured to allow users to 
monitor both analog and digital voice transmissions on the same frequency. 
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In Dynamic Mixed Mode, MOTOTRBO system does not enable some of the digital only 
features like IP Site Connect, Capacity Plus, Transmitter Interrupt and RDAC over IP. The 
system allows digital and analog voice transmission at one site. 

Once every analog radio has been swapped with a MOTOTRBO radio, the MOTOTRBO 
repeater can be reconfigured to fully operate in digital mode, therefore allowing the user to 
experience all available digital features. 

4.2.3 New/Full System Replacement 

The new/full system replacement strategy involves replacing all existing equipment with 
MOTOTRBO equipment. Typically, a new/full system replacement involves minimal downtime as 
the analog repeater is replaced immediately with the MOTOTRBO digital repeater. Radio users 
carry their existing radios as well as MOTOTRBO radios on cut-over day. Initially, users continue to 
access the radio system in the same manner as before. Once the analog repeater is removed from 
the system, the radio users switch to digital direct mode/dual capacity direct mode communication 
using MOTOTRBO radios. After the MOTOTRBO repeater is installed and becomes operational, 
radio users switch their MOTOTRBO radios to digital repeater mode. 

The new/full system replacement relies on the MOTOTRBO equipment being properly 
programmed and tested before being deployed. 
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4.3 Frequency Licensing 

4.3.1 Acquiring New Frequencies (Region Specific) 

The licensing process varies from region to region. Generally, before the license process begins, 
detailed information about the proposed radio system must be provided to the frequency 
coordinator, such as: 

• Frequency/ Frequency Band - Frequency band or specific frequency it operates on. 

• Subscriber Radio Count - The number of radios that will operate on the system. 

• Output Power/ERP - The output power of the system amplifier, as well as the effective 
radiated power (ERP), which is the system's power at the antenna. 

• Emission Designators - Includes several pieces of vital information, such as 
modulation, signal, type of information and size of the channel. This determines the 
channel width your system will occupy. For MOTOTRBO systems, the Emissions 
Designators are 

• Data only: 7K60FXD 

• Voice and Data: 7K60FXE 

The first four values are defined as the ‘Necessary Bandwidth’. This can be derived from 
the 99% Energy Rule as defined in Title 47CFR2.989. The next two values are the 
‘Modulation Type’ and the ‘Signal Type’. The final value is the Type of Information’ being 
sent. More information can be found with the region’s frequency coordinating 
committee. 

• International Coordination - For stations near another country’s border, refer to a 
frequency coordinating committee for licensing frequencies adjacent to that country. 

• Antenna Information - You must also provide the following information about your 
antenna: 

• Structure. The most common codes are: 

• B - Building with side mounted antenna 

• BANT - Building with antenna on top 

• MAST - Self-supported structure 

• PIPE - Pipe antenna 

• POLE - Any type of pole antenna 

• TOWER - Free standing guyed structure used for communications purposes 

• Height 

• Antenna Height - Antenna height from ground to tip, in meters. 

• Support Structure Height - If antenna is mounted on top of a building, it is 
the distance from ground to the top of the building. Check with the building 
management company for this information. 

• Coordinates - Latitude and longitude should be listed in degrees, minutes 
and seconds. 

• Site Elevation - The antenna site ground elevation above sea level. This 
information should always be in meters. 
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4.3.2 Converting Existing 12.5/25 kHz Licenses 

The process for converting 25 kHz to 12.5 kHz varies between regions. It is recommended to 
contact the local frequency coordinator’s office to inquire how to re-file existing frequency 
allocations. There are also consultants that specialize in frequency coordination and can advise on 
the filing process. In the US, the following are general guidelines for frequency licenses: 

• For existing 12.5 kHz license(s), the user needs to file an update to the emission 
designators indicating 7K60FXE (for voice) and 7K60FXD (for data) for all applicable 
frequencies. 

• If the user has existing 25 kHz licenses(s), they need to file an update to the emission 
designators to include 7K60FXE (for voice) and 7K60FXD (for data) for all applicable 
frequencies. Typically, the user will then be allowed to transmit a 12.5 kHz signal 
bandwidth at the same center frequency as the original 25 kHz license. Please note that 
it is not a straightforward process to convert an existing 25 kHz license into a pair of 12.5 
kHz channels. Users are generally NOT allowed to split their 25 kHz channel into two 
12.5 kHz sub-channels that would operate off center from the original license and 
adjacent to one another. 

4.3.3 Repeater Continuous Wave Identification (CWID) 

The repeater can be configured to transmit the CWID if required by the region. The CWID is also 
known as the Base Station ID. The CWID is an analog transmission of the station in Morse code 
that takes place every 15 minutes. This identification, as well as the transmit interval, can be 
configured in the repeater using the CPS. 

To ensure proper Dynamic Mixed Mode operation, only exclusive CWID transmission is supported 
in MOTOTRBO repeater operating in Dynamic Mixed Mode. Mixed CWID is not supported in order 
to be compliant with the digital mode of operation. Furthermore, the exclusive CWID transmission 
cannot be interrupted by either over-the-air transmissions or PTT transmissions by the repeater's 
accessories. 

4.3.4 Repeater Narrow IF Filter 

In 800/900 band, spectrum is often licensed in 12.5 kHz (10 channel) blocks. Recently, there have 
been requests to split the existing 25 KHz UHF channels into two 12.5 KHz channels for digital 
operation. There may be some requests in the future in VHF as well, since the standard does not 
prevent such usage. In contiguous channel allocation, Adjacent Channel Selection (ACS) 
degrades. 

If Adjacent Channel Selection (ACS) is poor, the following problems may occur: 

• Near/far adjacent channel interference scenario at the Repeater’s receiver : With a 
current protection of 57 dB, if signal on adjacent channel is 57 dB above desired signal, 
then there is 3 dB Rx degradation. 

• Impact to voice: There is 3 - 5 dB range from no audio to acceptable DAO 3.0 audio. 

• Impact to data: For confirmed data, there is 15 dB range that is impacted and results in 

more retries and lower throughput. 
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Interference from adjacent channel can be reduced by reducing the receive bandwidth. DMR 
modulation sideband power falls at 10 dB/kHz. 1 kHz narrowing of bandwidth would improve 
adjacent channel protection by 5 dB on each side. Decreasing receiver bandwidth requires 
mechanism to control reference oscillator drift over time (aging). Subscribers use high stability 
Repeater frequency to persistently tune the Subscriber reference oscillator. 900 requires 0.1 ppm 
this option is also available for 800. To support current deployments with no impact to range, there 
is a need to allow selection of Narrow or Wide (existing) filter in the repeater through a CPS option. 
This is applicable only to digital channels and NOT analog channels. Analog channels always use 
the default Wide IF Filter. Selection of narrow IF Filter improves ACS by 3 - 4 dB and degrades the 
sensitivity by 0.5 dB. 

The following configurations are recommended for system deployment: 

• For digital channels with adjacent channel separation of 12.5 kHz - select Narrow IF 
filter 

• For digital channels with adjacent channel separation greater than 12.5 kHz - select 
Wide IF filter 
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4.3.5 Capacity Plus and Linked Capacity Plus Part 90 Licensing 

Based on the Federal Communications Commission (FCC) rules in the United States, trunking 
radio service can be on shared channels or exclusive channels. To determine the type of license 
needed, please consider the following: 

• IG = Business/Industrial, Conventional 

• YG = Business/Industrial, Trunking (Capacity Plus and Connect Plus) 

• FB2 = Repeater on shared channel, internal systems 

• FB6 = Repeater on shared channel, for profit systems 

• FB8 = Repeater on exclusive channel 

In the 700/800/900 MHz bands, the channels are paired and normally licensed as exclusive. 

In the UHF band, the channels are paired and normally licensed as shared. It requires additional 
coordination effort to find and license exclusive channels. 

In the VHF band, the channels are not paired - base/mobile simplex channels - and are normally 
licensed as shared. It requires additional coordination effort to find and license shared repeater 
channel, and then the additional coordination effort to license repeater channels as exclusive. 

Centralized trunked systems, like Connect Plus, are usually high traffic systems with a dedicated, 
continuous Control Channel and are usually licensed on exclusive channels. Continuous Control 
Channel must be exclusive (FB8), but traffic channels could be either exclusive (FB8) or shared 
(FB2 or FB6). If the traffic channels are expected to have a high activity level, they should be 
exclusive (FB8). Shared traffic channels (FB2 or FB6) must be capable of monitoring channel 
before transmitting, which usually means lower channel traffic levels. 

Decentralized trunked systems, like Capacity Plus/Linked Capacity Plus, are usually lower traffic 
systems with intermittent data sent out over multiple traffic channels (and/or intermittent control 
data moves from channel to channel). They are usually licensed on shared channels. Shared 
traffic channels (FB2 or FB6) must be capable of monitoring channel before transmitting, which 
usually means lower channel traffic levels. If the traffic channels are expected to have a high 
activity level, exclusive channels (FB8) should be licensed. 

There are two levels of monitoring for shared channels: 

• Level 1 - Repeater monitors base receive channel for mobile activity (normal channel 
monitoring). The RSSI threshold setting in MOTOTRBO repeaters is used for FCC Type 
1 compliance, as it is used to measure the maximum interference signal that the 
MOTOTRBO repeater tolerates. 

The challenge with Level 1 monitoring is that there could be a 'hidden node' issue where 
distant foreign subscribers may not be heard. Same issue occurs on normal 
conventional repeater channels. 

• Level 2 - Requires separate remotely located monitor receiver on the repeater transmit 
frequency to listen to co-channel repeater output channel. This eliminates the 'hidden 
node' issue and is recommended if there is interference between systems using Level 1 
monitoring. 

NOTE: The above guidelines apply to part 90 services. Auction channels are still available in Part 
22 and Part 80 in the US. 
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4.4 Digital Repeater Loading 

The designer is able to choose the number of channels required to support his customer’s 
expected traffic after understanding how much traffic a single slot (channel) can support. The 
amount of traffic on a channel is dependent on numerous variables, which are difficult to estimate 
exactly at design time. Since MOTOTRBO comprises of Voice traffic, Text Messaging traffic, 
Location Tracking traffic, Registration and Signaling traffic, previous voice traffic only methods to 
gauge repeater capacity may not be sufficient. Because this traffic is mostly initiated by the end 
user, it is difficult to predict how often it occurs. Standard usage profiles of existing customers have 
been created for voice and data services. These profiles act as a baseline for estimating how 
much traffic a user creates on a system. If the standard profiles do not match your customer’s 
expected usage, further estimations based on the trend lines need to be considered. After the 
system is used, and real life usage is identified, further adjustments may be required. 

4.4.1 Assumptions and Precautions 

Channel loading analysis involves several assumptions: 

• Generalized high-level view of data and voice services interaction represents true 
interaction. 

• An estimated amount of blocking, interference, reliability, and call denials varies with the 
traffic profile and could change some of the results used. 

• An estimated number of radios using the location tracking feature (1 00%) and the rate of 
those messages for the high-end traffic profile (once every minute for every mobile) is 
used. 

Given these assumptions, the chart presented can be used to provide customers with a general 
rule of thumb for levels of user experience expected based on the number of users. In addition, for 
this analysis, the term “number of users” is used to indicate the number of active/participating 
users generating traffic, and does not include the number of users who monitor the activity of other 
radios on the channel. 





System Design Considerations 



285 



4.4.2 Voice and Data Traffic Profile 



The following table summarizes the standard traffic profiles for voice and data. The three traffic 
types considered are voice calls (Group Calls and Private Calls), data transmitted for location 
tracking and text messaging. For each traffic type, two levels are set. One, is for the case of a 
typical low usage or light traffic user, and the other is for a typical high usage or heavy traffic user. 
The voice and text messaging profiles are derived using assumed typical behaviors. 

These profiles act as a baseline for estimating how much traffic a user creates on a system. If 
these standard profiles do not match your customer’s expected usage, further estimations based 
on the trend lines need to be considered. Further, this is the profile of how all users on a channel 
will act together. It is understandable that not all users will use this profile all the time. These 
profiles should be used with Figure 4-1 to estimate the number of users per channel that yield an 
acceptable user experience. 



Profile 

Name 


Traffic Type 


Call Description 


Traffic Per User Per Hour 


High Voice 


Group Voice Call 


10 second call, 2 
transmissions per call 


3.0 Calls per User per Hour 


90% 


Individual Voice 
Call 


20 second call, 4 
transmissions per call 


10% 


Low Voice 


Group Voice Call 


10 second call, 2 
transmissions per call 


1 .0 Calls per User per Hour 


90% 


Individual Voice 
Call 


20 second call, 4 
transmissions per call 


10% 


High GPS 


Location Updates 


660 milliseconds (for 
Single Repeater and IP 
Site Connect) per 
transmission and 
540 milliseconds (for 
Capacity Plus mode) 
per transmission 


60 GPS Transmissions per User per Hour 
i.e. 1 Minute Update Period (Cadence) 


Low GPS 


Location Updates 


660 milliseconds per 
transmission 


6 GPS Transmissions per User per Hour 
i.e. 10 Minute Update Period (Cadence) 


High Text 
Messaging 


Text Messaging 


100 characters per 
message 


2.5 Text Messages per User per Hour 


Low Text 
Messaging 


Text Messaging 


100 characters per 
message 


0.5 Text Messages per User per Hour 
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4.4.3 Estimating Loading (Single Repeater and IP Site Connect) 

The following chart indicates the user experience level (the impact on the network) that the 
number of active users, using combinations of the defined profiles of “Voice and Data Traffic 
Profile” above, will experience. 

Each line in the chart has a combination of Voice, GPS, and Text Message at different usage 
levels. For example, the blue line identified as “Low Usage (Voice, GPS, Text)” represents a 
channel where each user transmits 1 Group Call an hour, 0.5 text messages an hour, and has a 
GPS Update Period (Cadence) of 10 minutes. If the defined profiles do not exactly match the 
estimated usage, the reader will need to extrapolate between two trend lines. 

There are two levels shown in the graph to describe user experience - good to fair. The good level 
means that the system is supporting this level well and if the customer is operating in this level the 
majority of the time, then the system is adequately provisioned. This means that the fair level may 
be reached for short periods of time as long as the system returns to supporting a lower level of 
traffic for the majority of the time. 

It is advised to avoid operating in the fair level when possible. If the customer experiences issues 
with reliability and/or call denial, this could indicate that the system is operating in the fair level for 
longer periods of time. If this occurs, the customer may require additional repeaters to support 
their traffic load. A system that operates in the fair level for the majority of the time results in longer 
wait times and having a significant number of unsuccessful attempts to acquire the channel on the 
user’s first attempt. These conditions would result in an unsatisfactory level of performance for the 
end users, even though the system itself is capable of operating in this region. 



X 

LD 



CD 

CO 

Z> 




High Usage (Voice, GPS, Text) 
High Voice, High GPS, Low Text 
Low Voice, High GPS, Low Text 
High Voice, Low GPS, Low Text 
High Voice Only 
Low Usage (Voice, GPS, Text) 
Low Voice Only 



Figure 4-1 Number of Users per Slot versus User Experience 



There are trends indicated in the chart that are worth noting. One is the impact in going from a Low 
Voice usage traffic environment to a High Voice usage traffic environment. The chart shows that a 
customer using the system for voice services only should be capable of supporting approximately 
45 users on the channel if the user traffic falls into the Low Voice usage traffic profile (one call per 
user per hour). However, if the customer intends to support a higher level of voice traffic, a single 
channel should be capable of supporting between 15 and 20 users and still remain in the good 
user experience level. It will always be difficult to accurately predict a customer’s usage as being 
either high or low. It is expected that most customers will operate somewhere in between these 
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two profiles. The designer must use knowledge of the customer’s organization and their expected 
usage to predict where on this chart they will operate. Note that the voice-only lines are a good 
frame of reference for existing customer with analog voice systems. These trend lines represent 
those of a voice-only analog system and a voice-only digital system. Understanding what user 
experience level a customer is currently operating at can help with predicting the new user 
experience, when adding data services. 

Two other trends from the chart are also worth pointing out. The first is that the level of adding data 
(low traffic for location tracking and text messaging) does not cause a huge impact to the number 
of users supported. For example the lines for High Voice usage traffic (one with voice only and the 
other with the addition of low location tracking and text messaging) both show that supporting 1 5- 
20 active users on one channel will keep the system from approaching the stressed level. 
Similarly, both curves for the Low Voice traffic show that 30-35 users could be supported well on a 
single channel. 

Another important note is that these trend lines are associated with a single slot of a MOTOTRBO 
repeater. Since MOTOTRBO is a two-slot TDMA system, a customer that is upgrading from a 
traditional FDMA one channel conventional system will have the ability to split users into two slots. 
For example, if a high usage voice only customer is currently supporting 30-40 users on a single 
channel, they are most likely operating in a “fair” or “stressed” environment, and will likely need to 
expand their system. If they switch to a MOTOTRBO system, they can divide their users into the 
two available channels. This means a single channel now has only 15-20 users, which would 
bring the customer back to a good user experience level. Subsequently, adding on low usage data 
services on both channels will cause minimal impact to performance. 

When GPS CSBK data is enabled, twice the number of radios can be supported with a similar 
GPS success rate. However, if the voice and TMS traffic are increased along with the number of 
radios, the voice and TMS user experience will drop. 

4.4.4 Estimating Loading (For Capacity Plus) 

The following charts (see Figure 4-2 and Figure 4-3) indicate the number of Trunked Channels (i.e. 
slots) a Capacity Plus system requires for a given user experience, for a given number of active 
users, and for different combinations of the Voice and Data Traffic profiles as defined in 4.4.2. It is 
assumed here that the number of groups are more than the number of channels. 

The charts represent a radio user’s experience in making a call in terms of Grade of Service 
(GoS). GoS is directly related to the probability of a call getting blocked i.e. probability of all the 
Trunked Channels being busy. For example, a GoS of 2% means that 2% of the calls made by the 
radio users will be either denied or will need to wait for a channel to become available. 

The “channel” in the chart refers to a logical channel (i.e. a slot). In Capacity Plus, both channels of 
a repeater are in either trunked mode or none. Therefore, the charts provide the number of users 
only for an even number of channels. 

The number of calls handled by a Capacity Plus system may vary considerably based upon the 
quantity of users and volume of calls. Most systems are heavily loaded for a few hours in a day. It 
is recommended that the system be designed with an adequate amount of channel resources to 
handle peak as well as off-peak traffic. 

The first chart is for High Voice profile (i.e. 3 Calls per User per Hour) with no GPS data. The same 
chart can also be used for other voice-only profiles by adjusting the “number of users” (i.e. the x- 
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axis) of the chart. For example, in the case of Low Voice profile (i.e. 1 Call per User per Hour), the 
“number of users” should be multiplied by three. 




—♦—High Voice Profile (2% GoS) 
-■-High Voice Profile (5% GoS) 
—A— High Voice Profile (8% GoS) 



Figure 4-2 Number of Users versus Number of Channels for Voice-Only Profile 
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Figure 4-3 is for mixed voice and GPS data profile. It has two sets of graphs - one for High Voice 
with low GPS data and the other for Low Voice with low GPS data. Both voice and GPS data are 
using the Trunked Channels. Take note of the trend indicated in the chart. The number of users do 
not increase proportionally with the number of channels. The rate increases as the number of 
channels increase. This is due to the fact that the efficiency of trunking increases with the increase 
in the number of channels. 




-♦-High Voice Low GSP (2% GoS) 
■ High Voice Low GPS (5% GoS) 
A High Voice Low GPS (8% GoS) 




Low Voice Low GPS (2% GoS) 
Low Voice Low GPS (5% GoS) 
Low Voice Low GPS (8% GoS) 



Figure 4-3 Number of Users versus Number of Channels for Mixed Profiles 
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In the case of high GPS data, it is recommended that a Capacity Plus system have exclusive 
channels for data called Data Revert Channels. Figure 4-5 shows graph for high GPS data over 
revert channels. A Data Revert repeater offers two Data Revert Channels and a revert channel can 
carry up to 20 location updates per minute with a success rate of 95% and 40 location updates per 
minute with a success rate of 85%. When GPS CSBK data is enabled, twice the number of radios 
can be supported with a similar GPS success rate. However, the trunked channel may not be able 
to support more radios. 
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Figure 4-4 Number of Location Updates versus Number of Data Revert Channels 

4.4.5 Estimating Loading (For Linked Capacity Plus) 
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If the number of Trunked Channels are not the same at all sites, the loading for Linked Capacity 
Plus can be estimated by first estimating the loading of a Capacity Plus system having ‘n’ Trunked 
Channels, where ‘n’ is the number of Trunked Channels at the smallest site. 

Example: For 12 trunked channels (i.e. 6 trunked repeaters), high voice only profile (See “Voice 
and Data Traffic Profile” on page 285), and Grade of Service = 2%, a Capacity Plus 
system can support approximately 700 radios (See Figure 4-2). 

A Linked Capacity Plus system handles the local calls as efficiently as Capacity Plus. Therefore if 
all calls are local, then for three sites, a Linked Capacity Plus system can handle 3 * 700 = 2100 
radios. 

If all the calls are wide area talkgroup calls, then the number of radios supported by a Linked 
Capacity Plus system is 700, which is the same as the number of radios supported by a Capacity 
Plus system. 

To estimate supported loading in both local and wide area talkgroup calls, assume the following: 

S = Number of sites (maximum of 3); 

W = Average number of sites associated with wide area talkgroups; 

L = Number of local calls as a fraction to total number of calls (e.g. if there are 500 local 
calls out of total 1500, then L=1/3); 
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With the above assumptions, the supported loading by a Linked Capacity Plus system is: 

R*S (L + (1-L)/W) radios, 

where ‘R’ is the number of radios supported by a Capacity Plus system. 

Example: For 3 sites (S=3), 12 trunked channels, 2% Grade of Service, one third local calls (L=1/ 
3), and an average of 2 sites associated with wide area talkgroups (W=2), a Linked 
Capacity Plus will be able to support 700*3 (1/3 +(1-1/3)/2) = 1400 radios. 

NOTE: 700 is the number of radios supported by a 12-channel Capacity Plus system at 2% Grade 
of Service. 

If the number of trunked channels is different at all the sites, the loading for Linked Capacity Plus 
can be estimated by first estimating the loading of a Linked Capacity Plus system having ‘n’ 
trunked channels, where ‘n’ is the number of trunked channels at the smallest site. This is 
explained in the following example. 

Example: An LCP system has four sites - A, B, C, and D. Sites A and B has two trunked repeaters 
and sites C and D has three trunked repeaters. Then, for 2% Grade of Service, one third 
local calls (L=1/3), and an average of 2 sites associated with wide area talkgroups 
(W=2), a Linked Capacity Plus will be able to support 120*4 (1/3 +(1-1/3)/2) = 320 
radios. Note that ‘120’ is the “number of users”, which comes from Figure 4-2 for 
number of channels = 4 and 2% grade of service. If the additional capacity at site C and 
D are designed for local calls, then Site C or Site D can support 240 users (refer to 
Figure 4-2 for number of channels = 6), that is, an additional 120 users at Site C and an 
additional 120 users at Site D. Thus, the total number of users supported by the system 
is 320 + 120 + 120 = 560 radios. 

In the case of high GPS data, it is recommended for a Linked Capacity Plus system to have 
exclusive channels for data defined as Data Revert Channels. Figure 4-4 shows a graph for high 
GPS data over revert channels. A Data Revert repeater offers two Data Revert Channels and a 
revert channel can carry more than 20 location updates per minute with a success rate of 95% and 
40 location updates per minute with a success rate of 85%. 

4.4.6 Loading Optimization (For Single Repeater and IP Site 
Connect) 

There are further considerations to take when configuring your MOTOTRBO system to ease the 
traffic load on a channel. These considerations should always be taken into account, especially if 
the designer is forced to operate outside of the “good” user experience range, although operating 
in such a manner is not recommended. 

4.4.6. 1 Distribution of High Usage Users 

It is good design practice to identify and distribute high usage users and groups between slots of a 
single repeater, or even other repeaters. This keeps the number of users that follow a high usage 
traffic profile to a minimum per channel. Groups are generally assigned to operate on a particular 
slot of a repeater. Through discussions with the customer, the designer should identify high usage 
groups and distribute them over different slots. 

Groups and users that are on different slots cannot communicate with each other. They need to 
manually change their selector knobs to communicate with the users and other groups on the 
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other slot. In most cases, this is not a problem since organizations can usually be broken into at 
least two groups of users. But in the case where a customer only has one group of users who all 
need voice communication between each other at all times, then evenly distributing the voice and 
data load between two channels becomes more complicated. 

If there is only one group in a system, its users can all be programmed to operate on a particular 
slot. Their Group Calls, Private Calls, text messages, location updates will all be transmitted on the 
programmed slot. This is an acceptable configuration, although it leaves the other slot completely 
unused. If the number of users and their usage grows, the slot may be unable to support their 
traffic. For example, if a customer has 50 users with voice and GPS usage all on one time slot, 
their user experience may be poor due to the traffic loading. It is highly recommended that the 
users in this case be broken into two unique groups of 25, and distributed between the slots. 

In the event, that all users could be broken into two unique groups, but are required to maintain 
voice communication with each other, the solution is to split the same group across the two slots, 
and enable scan. One half of the group should be assigned to slot 1 , and the other half assigned to 
the same group, but on slot 2. They should use the same group number. This can be done by 
having two channels with the same frequencies but different slots, and with the same group as the 
TX Call Member. All radios should include both (and only) these two channels in their selected 
Scan List. Scan hang time duration should be set to the Group Call hang time duration in the 
repeater, which defaults to two seconds. Talkback scan should always be enabled so that users 
can talkback during the scan hang time. When assigning all users to the same group, the use of 
scan primarily serves to aggregate the multiple channels into a single logical channel for voice. 
Location data will be transmitted out the selected channel when no voice is taking place. Therefore 
location data will be evenly distributed across two slots. Note that when a voice call occurs, all 
radios will scan and land on a particular slot. The other slot will be empty at this time since all 
radios will be monitoring the voice call. 

The drawback of this operation, and why it is not generally recommended, is that this configuration 
essentially cuts the voice capacity of a repeater in half since only one voice call can take place at 
any given time, although this does allow for data transmission to occur at the same time on the 
different slots of a repeater. Furthermore, if two radios transmit at the same time on different slots, 
some of the radios will scan to one slot, and some will scan to the other slot. It is not possible to 
predict the distribution since all radios are scanning. Also note, that while scanning, the probability 
of missing a voice header and entering a call “late entry” increases, therefore missed audio may 
occur. Because of these drawbacks, it is highly recommended to break users into at least two 
unique groups and distribute them across slots, and only use this scanning strategy if completely 
necessary. 

4.4. 6. 2 Minimize Location Periodic Update Rate 

The high usage location profile defined assumes that every user on the channel has location 
capability and uses a 1 minute refresh rate. In actual fact, if every user actually has a 1 minute 
refresh rate, this increases the traffic loading tremendously. It is recommended that users be 
configured to use a 10 minute update, and to only increase individual radios to a 1 minute update 
rate during emergencies or special situations. Although each customer scenario may be different, 
knowing a user’s location every 10 minutes is usually considered sufficient. If a user reports an 
emergency, his location update rate can be increased by the location dispatcher for a short period 
of time. The minimum interval between updates (High Cadence setting) can be set as low as 10 
seconds, but with the concerns mentioned above kept in mind. 

In order to help visualize the impact of setting the Location Update Period between 1 minute and 
10 minutes, the following graph was created using the data presented in Figure 4-1. The following 
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assumes a specific desired user experience (approximately mid-way between good and fair). The 
graph was plotted using the intersection of the Low GPS (10 minute Cadence) and High GPS (1 
minute Cadence) lines for High Voice and Low Voice with the desired user experience design goal. 

The chart provides a method to easily set the Location Update Period for a particular number of 
users on a channel, while keeping their voice usage in mind. The intersection between the number 
of users and the Location Update Period should always be above the line for the applicable voice 
usage. For example, if a channel has 10 users, and the users have been determined to be High 
Voice users (3 calls per user per hour), then it is recommended that the Location Update Period be 
set to 3.5 minutes or higher (longer). Because it is very difficult to determine the true voice usage 
profile, the administrator/dealer needs to make a judgment call on whether the usage leans 
towards the High Voice Usage trend or the Low Voice Usage trend. 

Although the impact is not substantial, it should be noted that utilizing a high cadence location 
update rate lowers the overall battery life of the radio since it will be transmitting often. 
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Figure 4-5 Number of Users versus Location Update Period 



The value chosen for the location periodic update rate directly affects scan performance. Most 
users realize that a radio pauses scanning when transmitting voice, and then resumes scanning 
once the voice transmission is over. The more voice a user transmits, the less the radio is 
scanning, which means, its probability of missing traffic increases. This is also true when 
transmitting data. The more a radio transmits data, the less it is scanning, and therefore the higher 
the probability of missing traffic. Additionally, if the channel used to transmit the data is busy, it will 
take longer to deliver the message; therefore the radio's scanning will be further interrupted. This 
means that the higher the location periodic update rate is for a radio, its scan performance will 
degrade. This should be kept in mind when using scan with a high cadence location period update. 
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It is recommended that radios be configured to use a 10 minute update, and that scanning radios 
should NEVER use a value lower than 2 minutes. 
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4.4. 6. 3 Data Application Retry Attempts and Intervals 

The interval a data application will retry to send a message and the number of retries it will send if 
the target does not respond is configurable in the external data applications like Location and Text 
Messaging. The following table shows the default values provided: 



External Data 
Application 


Number of 
Retries 


Interval Time Period between 
Retries 


Text Messaging 


2 


70 seconds 


Location Application 


3 


30 seconds 



It is recommended to not change the default values. If this value is lowered too low, messages 
may become unreliable when a user is on the system, but will free up some bandwidth if the user 
is not available. Increasing too high until it is past the default will increase the load on a channel 
although it may increase the probability of delivering a message. 

4.4. 6.4 Optimize Data Application Outbound Message Rate 

Text Message and Location Applications both have the ability to set the outbound message rate. 
The outbound message rate is defined as the interval in-between subsequent messages sent by 
the applications to its connected control stations. It is important to note that the Application Server 
is connected to up to four channels, and is not aware of which channel is used to route a message. 
It is the function of the MCDD to track users, and send messages out the appropriate channel. 
Therefore, it is reasonable that the outbound message rate setting be increased to a greater value 
than the default, if there is more than one channel on a system. The default value for the text 
message server is 14 messages per minute distributed uniformly. The default value for the 
Location Server is 20 messages per minute, distributed uniformly. 

For example, if a system only has one data capable channel, and therefore only one control 
station, the default value of the Outbound Message Rate paces the messages appropriately to not 
overload the control station or add excessive load to the channel. If there are more than one 
channel (2 to 4 channels), and the users are distributed fairly evenly over these channels, the 
Outbound Message Rate could be increased, since only a portion of the messages will be going to 
any single channel. It is difficult to predict which channel users will be registered on, and even 
harder to predict how many messages will be sent to a particular user on a particular channel. 

It is recommended that the outbound pacing rates remain as default, though special 
considerations for GPS Revert are discussed in “GPS Revert and Loading” on page 296. If they 
are increased, and the target radios are not evenly distributed over multiple channels, one channel 
may experience excess loading. The MOTOTRBO radio can buffer only up to 10 messages. If 
there is RF congestion on the system, the radio may encounter a situation where its message 
transmit buffer becomes full. This is due to the radio queuing up messages, because it cannot find 
an available slot to transmit data. The radio will not be able to process new messages from the 
application, once its buffer becomes full. 
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4.4. 6. 5 GPS Revert and Loading 

The GPS Revert feature supports the transmission of voice, control and non-location update data 
transmissions on the Selected Channel, while off loading Location updates onto one or more GPS 
Revert Channels. A primary goal of the feature is to support location updates without degrading 
features on the Selected Channel. The ultimate performance of the system will depend upon at 
least two loading factors (1 and 2), while a third loading factor (3) needs to be considered if most 
radios are powered on in a relatively short period of time. These factors are listed below. 

1 . The average number of transmissions on the Selected Channel (Voice, Text Messaging, etc.). 

2. The average number of transmissions on a GPS Revert Channel. 

3. The peak number of transmissions on the Selected Channel to account for registration 
and periodic re-registration messaging. 

The chart in Figure 4-6 illustrates the Good to Fair user experience area, similar to that in Figure 4- 
1, for voice traffic loading on the selected channel and GPS traffic loading on one or more GPS 
Revert Channels. Note that this only accounts for loading the first and second factors and 
assumes registration messaging is evenly spread throughout the day. 



Selected Channel and GPS Revert Channel Loading with High GPS 




# of Users per Slot 



Figure 4-6 Channel Loading with GPS Revert Channels 

It can be seen in Figure 4-6 that the High Voice Selected Channel User Experience and the single 
GPS Revert Channel User Experience are fairly similar in terms of user experience versus number 
of users on a slot. In this example, for the desired User Experience (identified on the above chart 
as the red horizontal example line), the Selected Channel supports about 16 radios at a High Voice 
profile and the single GPS Revert Channel supports about 18 radios at a high GPS profile. For the 
High Voice profile, which is defined in “Voice and Data Traffic Profile” on page 285, 16 users would 
equate to a little less than 2 transmissions per minute. For a high GPS profile, which is also 
defined in “Voice and Data Traffic Profile” on page 285, 18 users would equate to 18 transmissions 
per minute. 

It can also be seen in Figure 4-6 that the Low Voice Selected Channel User Experience and the 
three GPS Revert Channel User Experience are fairly similar in terms of user experience versus 
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number of users on a slot. In this example, for the desired User Experience, the Selected Channel 
supports about 51 radios at a Low Voice profile and the three GPS Revert Channels support about 
57 radios at a high GPS profile. For the Low Voice profile, which is defined in “Voice and Data 
Traffic Profile” on page 285, 51 users would equate to a little less than 2 transmissions per minute. 
For a high GPS profile, which is also defined in “Voice and Data Traffic Profile” on page 285, 57 
users would equate to 57 transmissions per minute, distributed over three channels. 

In the previous examples, it can be seen that the voice rate and the GPS rate cannot always be 
considered as independent when designing a system. Though three GPS Revert Channels are 
able to support 57 high GPS profile users, the Selected Channel is unable to support 57 High 
Voice profile users. Therefore, when designing a system, both the Selected Channel loading and 
the GPS Revert Channel(s) loading must be thoroughly considered. 

The table below provides guidance for determining the maximum number of radios supported on 
various numbers of GPS Revert Channels with one minute and two minutes update rates. It is 
important to note than maximum loading will essentially keep a repeater keyed up at all times. 
Update rates of less than one minute are not recommended in order minimize the impact on the 
Selected Channel features (voice, control and/or data). Care must also be taken to analyze if the 
Selected Channel can accommodate the anticipated voice traffic for a large number of 
subscribers. 





1 GPS Revert 
Channel 


2 GPS Revert 
Channels 


3 GPS Revert 
Channels 


Radios supported at 
1 minute update rate 


20 


40 


60 


Radios supported at 
2 minute update rate 


40 


80 


120 



When GPS CSBK data is enabled, twice the number of radios can be supported with a similar 
GPS success rate. However, the home channel may not be able to support more radios. 

Though GPS Revert Channels can significantly increase the number of radios providing location 
updates, it is important to remember that when powered up, an radio needs to register with both 
Presence and Location Applications before it can send location updates. If a large number of 
radios happen to be powered up in a relatively short period of time, the Selected Channel may 
become overwhelmed with registration traffic and the system’s voice handling capacity will be 
impacted. Therefore, if this situation must occur, the following should be kept in mind. 

• Keep voice traffic on the Selected Channel to a minimum. This causes the registration 
messages to be queued in the radio and the control station. 

• As a rule of thumb, expect about three successful registrations per minute. Therefore, a 
fleet of 60 radios could require 20 minutes to successfully register. In order to minimize 
registration traffic, the radios can be gradually powered on at a rate of three per minute 
during the estimated time frame. 

When using Motorola applications, it is possible to modify certain settings to make the registration 
process more efficient. The following steps should be used to modify the MotoLocator Application: 

1. Locate the Configuration. xml file and open in Notepad. The default path is 

C:\Program Files\Motorola\MOTOTRBO Location Services\MotoLocator\bin\Configuration.xml 

2. Modify the value of “aveDelay” from 3000 to 6000. 

NOTE: This will decrease the number of location messages per minute sent to the radios. 
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3. Open the MotoLocator Administrative Client. 

4. Click on the Server tab to see the Server Status page. 

5. Click on Stop and then click on Start to restart MotoLocator. 

If the TMS is also being used, it places an additional load on the channel during registration. The 
following steps may be used to modify TMS if it is also being used: 

1 . Open the TMS Administrative Client. 

2. Click on the Text Messaging Administrative Client. 

3. Click on Configuration Management => System Configuration => TMS Service. 

4. Modify the value of “Average Message Pacing Rate (msg/min)” to a smaller value than the 
default value. 

NOTE: The larger the number of initial registrations expected in a short amount of time, the 

smaller this value should be. However, decreasing this value will impact the rate at which 
text messages are sent from the TMS to the radios. 

5. Return to the main menu on the TMS Administrative Client. 

6. Click on Stop and then click on Start to restart TMS. 

Generally, a GPS Revert Channel can support more radios when a lower GPS update rate (i.e., 
larger update period) is being used. On the contrary, the channel supports fewer radios if a higher 
update rate (i.e., smaller update period) is being used. The following chart illustrates the 
relationship between the location update period and number of radios assigned to a particular 
GPS Revert Channel. When the CSBK data feature is enabled, twice the number of radios can be 
supported. The blue line in Figure 4-7 Minimum Location Update Period versus Number of 
Subscribers illustrates this case. 

Example 1 : No more than 20 radios should be assigned to a particular GPS Revert Channel, if an 
update period of 60 seconds (i.e., 60 updates per hour) is desired. 

Example 2: If 120 radios are assigned to use a GPS Revert Channel, the minimum recommended 
update period is 360 seconds (i.e., 10 updates per hour). 

Hence, some flexibility is provided as to whether a large number of radios with a slow update 
rate, or a small number of radios with a fast update rate is used on a GPS Revert Channel. 
Alternatively, depending on whether having a large number of radios assigned to a GPS Revert 
Channel or having a fast update rate is more desirable for a particular system, the system can be 
provisioned to accommodate either scenario. 

A higher GPS update rate can impact the service (voice, control and/or data) presented on the 
channel selected by the radio user because the radio spends a longer time transmitting its GPS 
location on the GPS Revert Channel. The recommended rate is to not exceed 60 GPS updates 
per hour per radio (i.e., 60-second GPS update period). 
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4.4. 6. 6 Enhanced GPS Revert - Loading & Reliability 

This section is applicable to all three configurations of MOTOTRBO - IP Site Connect, Capacity 
Plus, and Linked Capacity Plus. 

The number of subscribers supported on an Enhanced GPS slot is a function of the window size, 
(derived from the size of the location data), and the update rate. Additionally, the success rate of 
the location updates is also a function of the call duration on the selected/primary channel and the 
repeater loading. The following figures illustrates the relationship between these variables. 

The curves in Figure 4-8 illustrate the average location update success rate against the number of 
subscribers for a 1 -minute update rate per subscriber, a 10-second call for the talkgroup per 
minute and 75% repeater loading 1 . If there are no talkgroup calls, the subscribers would update 
100% of the time as long as the number of subscribers are less than or equal to the maximum 
number of allocated reserved windows. (The maximum allocated reserved windows is the repeater 
loading.) 

However, voice calls keeps a subscriber from sending location updates on its reserved slot. Hence 
the subscriber makes a request to send in the data on the unreserved windows after the call. 
Therefore in Figure 4-8, it is noticeable that larger talkgroups (more subscribers) decreases the 
average success rate. This is because there are not enough unreserved windows to support all the 
missed reserved data transmissions. 



1. Loading here refers to percentage of periodic window reservation. 
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Figure 4-8 describes the location update success rate against the number of subscribers when the 
CSBK data feature is enabled. The data in the figure is obtained from simulation, that should only 
be used for initial system planning. Actual testing is still required to adjust the group call size, 
periodic GPS loading and update rate. Keep in mind the following notes: 

1. Window size 1 cannot support dedicated requests. The radios will request a one-time 
window to send the GPS update missed periodic window. A big group size will cause 
many radios to miss the periodic window after a group voice call, while a 90% periodic 
loading cannot reserve many free windows. Therefore a big group size cannot be 
supported by window size 1 with 90% loading. 

2. With other conditions being the same, window size 2 can support a bigger group size than 
window size 1. It is more apparent when the periodic GPS loading is higher. 

3. With other conditions being the same, window size 1 can support a bigger group size than 
window sizes 5 to 10 when the periodic GPS loading is 45 or 60. 
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Figure 4-8 One Minute Update Rate with Different Window Sizes, Loading and Call Duration 
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4.4.7 Loading Optimization (For Capacity Plus and Linked Capacity 
Plus) 

4.4.7. 1 Preference for Using a Frequency 

The Capacity Plus and Linked Capacity Plus systems are designed to operate efficiently in a 
shared channel environment. The term “shared channel environment” is typically used when more 
than one system uses the same frequency for communication within the same coverage area. For 
system owners having licenses for shared use of frequencies, it is recommended to set a 
preference level for the use of a frequency. A repeater whose frequencies have lower interference 
from other system(s) should be given higher preference level over the repeater whose frequencies 
have higher interference. Repeaters with the same amount of interference should have the same 
preference level. For trunking operation, a Capacity Plus/Linked Capacity Plus system always 
prefers to use a repeater of a higher preference level over a repeater of lower preference level. 

For system owners having a mix of shared frequency channel licenses and exclusive frequency 
licenses, the repeaters with exclusive frequency licenses should have a higher preference level 
than the repeaters with shared frequency licenses. 

4.4. 7. 2 Improving Channel Capacity by Adjusting Hang Times 

MOTOTRBO supports message trunking by keeping a channel reserved for the duration of hang 
time after a transmitting radio has unkeyed the microphone. During the hang time, only the 
members of the ongoing call can start a transmission. The advantage of the message trunking is 
that it provides guaranteed access to the channel for the duration of a call. The disadvantage of 
the message trunking is that the channel remains unused during the hang times. To improve 
channel utilization, a customer may choose to reduce the call hang time in the repeater. 
Experienced radio users respond quickly and therefore require a shorter hang time. 

Capacity Plus/Linked Capacity Plus allows a customer to program a near zero call hang time in 
repeaters. By programming a zero call hang time, MOTOTRBO acts as if the channel is allocated 
for only one transmission and in this case, MOTOTRBO supports Transmission Trunking. 

However, there are some trade-offs in reducing call hang time. The channel will no longer be 
reserved for a group in the system. Thus, every time a group member of the same call presses 
PTT to initiate a call, the call will land on a different frequency channel. In some cases, some of the 
Group Call participants may switch to other high-priority Group Calls. While in other cases, the 
system may become busy with other calls and no channels are available to initiate the call. 

Customers may choose to reduce call hang time from the default value rather than setting it to 
zero based upon channel usage. If there are more members in a group, and if members of the 
group are replying instantly to the Group Call, then lowering call hang time from the default value 
may improve overall call throughput. However, if the group members are not replying instantly to 
the communication and the channel still needs to be reserved, then call hang time should be 
increased. Call throughput reduces by increasing call hang time and vice versa. 

Since all repeaters in the system needs to exhibit the same behavior, it is recommended that the 
same call hang time is programmed in all trunked repeaters. 
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4.4. 7. 3 Call Priority 

A radio joins its most preferred call in the following conditions: 

• The call that the radio was participating in, ends, 

• A radio powers on, or returns from a fade when all Trunked Channels are not busy. 

The preference list for a radio (in decreasing order) is an Emergency Call of interest, All Call, the 
radio’s transmit group, and the radio’s receive group list. The preference of groups in a radio’s 
receive group list are displayed in decreasing order. 

A radio enforces the call priority only when it enters a call. Upon joining the call, the radio searches 
for only All Calls and Emergency Calls whereby the emergency group is in either the transmit 
group, or the receive group list. 

4.4. 7.4 Call Initiation 

In Capacity Plus/Linked Capacity Plus modes, while a radio is listening to a Group Call, a radio 
user can initiate a non data call (e.g. using the menu). The radio moves to the Rest Channel and 
starts the requested call if there is an idle channel. If all channels are busy, the radio informs the 
user (by generating a busy signal) that the call cannot be initiated and the radio stays on the traffic 
channel. 
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4.5 Multiple Digital Repeaters in Standalone Mode 

Multiple repeaters may be required to provide sufficient RF coverage. Large geographical regions 
and areas with large natural boundaries (i.e. mountains) are two examples. Also, regions with a 
large number of subscribers may need additional repeaters to relieve RF congestion. 

The digital mode of operation of the MOTOTRBO repeater provides new capabilities to resolve 
common problems associated with deploying multiple repeaters in a system. The techniques 
described in the sections below can also be used to resolve problems associated with interfering 
RF signals from adjacent radio systems. 

4.5.1 Overlapping Coverage Area 

As with analog radio systems, when digital radio systems are separated by frequency or distance 
there are no negative interactions between the systems which need to be addressed. Figure 4-9 
shows two systems which operate on a common set of frequencies but are physically separated 
so that there are no interactions between the systems. 




Figure 4-9 Multiple Repeaters 

Similarly, Figure 4-1 0 shows two systems which overlap in space but operate on a difference set of 
frequencies so that there are no negative interactions. 




Figure 4-10 Multiple Repeaters with Overlap 
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Issues arise, however, when repeaters operate on common frequencies and have overlapping 
regions. Figure 4-11 shows that when a radio transmits in a region of overlap, repeaters from both 
systems retransmit the received signal. Analog radio systems often use PL/DPL to resolve these 
types of problems. With the MOTOTRBO repeaters operating in digital mode, this issue can be 
resolved by assigning a unique color code to each repeater and programming the associated 
radios, using CPS, with the matching color code. 




Figure 4-11 Multiple Repeaters with Overlap and Common Frequencies 

4.5.2 Color Codes in a Digital System 

Color codes (or “CC” in the images) are defined by the Digital Mobile Radio (DMR) standard and 
can be used to separate two or more MOTOTRBO digital radio systems which operate on common 
frequencies. Figure 4-12 shows two MOTOTRBO radio systems which operate on common 
frequencies but have uniquely defined color codes. 




Color codes are assigned as channel attributes on the radios, allowing a single radio to 
communicate with multiple sites each having a uniquely defined color code. 
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4.5.3 Additional Considerations for Color Codes 



The total number of available color codes per frequency is 1 6. From a radio user’s perspective the 
color code is similar in nature to a Group ID. However, it should not be used for this purpose. Just 
as Groups are intended to separate users into groups, the color code is intended to uniquely 
identify systems or channels which operate on common frequencies. 

Multiple repeaters operating on common frequencies with large areas of overlap, as shown in 
Figure 4-13, could be configured with unique color codes. This would allow both repeaters to 
operate with some degree of independence. However, the radio users should expect to see an 
increase in “Channel Busy” indications since transmissions from both repeaters will be detected by 
users of both systems. In other words, the RF congestion for this region would be the sum of 
transmissions from both repeaters. It should be noted that under all circumstances the users with 
the correct corresponding color codes receive only the transmission intended for them. 

When two sites with the same frequency but different color codes overlap, it is important to set the 
subscriber’s Admit Criteria appropriately. It is recommended that the subscribers are provisioned 
with Admit Criteria set to Channel Free to ensure subscriber’s from a Site is polite when another 
on the overlapping Site is transmitting, and also polite to any other analog transmission on the 
frequency. If configured to Color Code Free, the subscribers are only polite to their own color code, 
and will wake up their repeater even if the other repeater is currently transmitting. When there is a 
large overlap between adjacent sites, this usually causes major interference and results in both 
repeater signals being unusable in the overlapping areas. When configured to Always, the 
subscribers are never polite, even to their own color code. Again, this results in both repeaters 
being awake and transmitting at the same time which causes interference in areas of overlap. 

If this configuration is necessary, it is recommended to minimize the areas of overlap as much as 
possible and to use an Admit Criteria of Color Code Free. Remember that these two repeaters will 
be sharing bandwidth and should be loaded appropriately. 




Figure 4-13 Color Code with Site Congestion 



System Design Considerations 



307 



4.6 Multiple Digital Repeaters in IP Site Connect Mode 

The main problem with the standalone configuration of multiple digital repeaters is that a radio at a 
site can participate only in the calls that originate at that site. The IP Site Connect configuration 
removes this restriction and allows a radio to participate in a call originating at any site. In IP Site 
Connect configuration, repeaters communicate among themselves using a backend wire line 
network. A call originating at a repeater is transmitted by all the repeaters in the IP Site Connect 
system. Since all repeaters participate in a call, it is necessary that all the repeaters have the same 
call related parameters (e.g. Call Hang Times, System Inactivity Time, Time Out Time). 

4.6.1 System Capacity 

In IP Site Connect configuration, MOTOTRBO supports a maximum of 15 IP Site Connect devices, 
where IP Site Connect devices include a maximum of five host PCs of RDAC-IP applications, 
disabled repeaters, enabled repeaters in analog mode, and enabled repeaters in digital mode 
(both slots in wide area mode, one slot in wide area mode and one in local mode, and both slots in 
local mode). 

A channel in IP Site Connect configuration supports the same number of radios supported by a 
single site configuration. Note that an IP Site Connect configuration increases the coverage area 
and not the call capacity of a single site configuration. 

4.6.2 Frequencies and Color Code Considerations 

The figure below shows an example of two IP Site Connect systems with overlapping coverage 
areas. The frequencies and color code of repeaters should follow the following rules: 

• The geographically adjacent repeaters of an IP Site Connect system should use 
different frequencies. Their color code can be either same or different. 

• If the frequencies of the geographically adjacent repeaters of two IP Site Connect 
systems are the same, then their color codes should be different. It is not advisable to 
keep the same frequencies because in areas of overlap, there will be destructive 
interference. Note that an IP Site Connect configuration does not support simulcast. 

• If the frequencies of non-adjacent repeaters of an IP Site Connect system are the same, 
then their color codes should be different. It is not advisable to keep the same 
frequencies and color code because a roaming radio is not able to distinguish between 
them, and may use the wrong GPS Revert Channels or emergency system. 

• A system may be sharing the channels with other systems over multiple sites. It is 
possible that two systems (named here as Sysl and Sys2) may be using the same 
(frequencies, color code) pair at two different sites (say, Sitel and Site2). During 
automatic site search (Passive Site Search), a Sysl’s radio at Site2 will find Sys2’s 
repeater and will stay on that channel. This is not a desirable situation. A way to avoid 
this situation is to ensure that all the (frequencies, color code) pairs of all the overlapping 
systems are unique. 
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System 2 



Figure 4-14 Example of Two IP Site Connect Systems with Overlapping Coverage Areas 



4.6.3 Considerations for the Backend Network 



The backend network can be a dedicated network or an internet provided by an Internet Service 
Provider (ISP). ISPs provide a range of technologies such as dial-up, DSL (typically ADSL), Cable 
modem, Broadband wireless access, Canopy, ISDN, Frame Relay, Satellite Internet access, etc. 
In some cases dedicated links or networks can be effectively used or deployed, removing the 
monthly fees associated with public networks. The backend network cannot be based on dial-up 
connection (due to small bandwidth) or Satellite Internet access (due to large delay). 

A repeater has three network interfaces: Ethernet, USB, and over-the-air. A repeater uses its 
Ethernet port to communicate among them using IPv4/UDP. Since UDP does not support 
confirmation, an IP Site Connect system provides its own acknowledgement and retries 
mechanism for critical activities. Note that the Ethernet port is not a default IP gateway of a 
repeater, i.e. an IP datagram arrived from USB or over-the-air is not automatically routed to the 
Ethernet port. 

It is not necessary to get a static IPv4 addresses for IP Site Connect devices (except for the 
Master). The IPv4 address of an IP Site Connect device can be dynamic. In this case, the IPv4 
address is allocated by a DHCP server. The dynamic nature of the IPv4 address implies that the 
address may change every time it powers-on or even periodically (every few hours) while the IP 
Site Connect device is on. The dynamic address of a repeater is selected by selecting the DHCP 
option in the repeater CPS. It is recommended that the lease time of the IPv4 address from the 
DHCP should be kept as long as possible. Note that a change in the IPv4 address of an IP Site 
Connect device causes short disruption of service for the device. For static IPv4 address, the 
DHCP option should not be selected and the CPS user should provide the static IPv4 address, 
and the gateway’s IPv4 address and netmask. 

An IP Site Connect configuration uses a procedure called “Link Management” to keep an IP Site 
Connect device aware of the presence, the current IPv4 addresses, and UDP ports of other IP Site 
Connect devices. The Link Management requires only one of the repeaters (called an Master) to 
act as a broker of IPv4/UDP addresses. The Master gets a static IPv4 address from its ISP and the 
Master’s IPv4/UDP address is configured into all the IP Site Connect devices. 
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The Master’s IPv4/UDP address refers to its address as seen from the backend network. Note that 
a firewall/NAT may translate the address in customer network into another address in the backend 
network. 

An IP Site Connect device registers its IPv4/UDP address during power-on and upon a change in 
its IPv4/UDP address with the Master. The Master notifies to all the IP Site Connect devices 
whenever the IPv4 address of an IP Site Connect device changes. An IP Site Connect device 
maintains a table of the latest IPv4 addresses of other IP Site Connect devices and it uses the 
table to send an IPv4/UDP message to another IP Site Connect device. 

The IP Site Connect devices may be behind firewalls. For successful communication between two 
IP Site Connect devices (say R1 and R2), the firewall of R1 must be open for messages from R2 
and vice versa. Since the IPv4/UDP address of an IP Site Connect device is dynamic, it is not 
possible to manually configure the firewalls. The Link Management procedure overcomes this 
problem by periodically, for example, setting the Keep FW Open Time to every 6 seconds, sending 
a dummy message from R1 to R2 and vice versa. On a receipt of an outbound message (say, from 
R1 to R2), the Rl’s firewall keeps itself open for a short duration of approximately 20 seconds for 
an inbound message from R2. An IP Site Connect device (say, R1) sends the dummy message to 
another IP Site Connect device (say, R2) only if R1 has not sent any message to R2 in last Keep 
FW Open Time. The value of Keep FW Open Time is customer-programmable and should be kept 
less than the duration for which the firewall remains open for inbound messages. Exchange of 
dummy messages between two IP Site Connect devices also acts as a “Keep Alive” messages. 
They are required, even if there is no firewall or the firewall is configured to keep itself open for any 
message transmitted to the IP Site Connect device. 

4.6.3. 1 Automatic Reconfiguration 

An IP Site Connect system automatically discovers the presence of a new IP Site Connect device. 
The new IP Site Connect device is configured with the IPv4/UDP address of the Master. On 
power-on, the new IP Site Connect device informs its IPv4/UDP address to the Master and the 
Master informs all the other IP Site Connect devices about the presence of a new IP Site Connect 
device. This allows adding an IP Site Connect device to a live IP Site Connect system. This 
simplifies the installation/addition of an IP Site Connect device as there is no need to take the 
system down and configure other IP Site Connect devices with the IPv4/UDP address of the new 
IP Site Connect device. 

The periodic link management messages between an IP Site Connect device and the Master also 
act as “keep alive” messages. In absence of messages from an IP Site Connect device for one 
minute, the Master concludes that either the IP Site Connect device has failed or the network in- 
between and the Master informs all the other IP Site Connect devices about the absence of the IP 
Site Connect device. An IP Site Connect device also maintains periodic link management 
messages with every other IP Site Connect device. In absence of messages from another IP Site 
Connect device for one minute, the IP Site Connect device concludes that either the other IP Site 
Connect device has failed or the failure is within the network in between. Thus, the link 
management messages allow an IP Site Connect system to reconfigure itself on failure of one or 
more IP Site Connect devices and the system continues to provide services with the available IP 
Site Connect devices. In case of network failure, it is possible that an IP Site Connect system 
becomes multiple IP Site Connect systems, where each system has a subset of original set of IP 
Site Connect devices. All the new systems continue to provide the services that are possible with 
their subset of IP Site Connect devices. Note that there will be only one system that has the 
Master. When the backend network recovers, the multiple systems automatically become one 
system. When an IP Site Connect system has only one repeater, then both the slots of the 
repeater repeat only locally (i.e. over-the-air) as per the MOTOTRBO Single Site specifications. 
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A repeater operates in multiple modes such as disabled, locked, knocked down, enabled and 
analog, enabled and digital with voice/data or control services, and single or multiple site operation 
for each slot. The repeater informs the Master whenever its mode of operation changes and the 
Master informs to all the other IP Site Connect devices. This allows the IP Site Connect system to 
adapt its operation when the mode changes. Note that only an enabled and digital repeaters (with 
a channel enabled for multiple site operation) participate in voice/data/control communication 
across multiple sites. 

A disadvantage of link Management is that the Master becomes a single point of failure. But the 
consequence of failure of the Master is limited. The IP Site Connect system continues to function 
except that it is not possible to add an IP Site Connect device into the system. If an IP Site 
Connect device powers on, while the Master is in failed state, then it will not be able to join the IP 
Site Connect system. On failure of the Master, it is possible to switch a redundant IP Site Connect 
device to act as an Master. The static IPv4 address and the UDP port number of the redundant IP 
Site Connect device should be same as that of the failed Master; otherwise all the IP Site Connect 
devices will require to be reconfigured with the IPv4 address and the UDP port number of the new 
Master. 

4. 6. 3. 2 Characteristics of Backend Network 

To create a proper backend network design, it is important to know its characteristics. This section 
explains four issues dealt within the backend network. 

4. 6. 3. 2.1 Delay/Latency 

Backend network delay or latency is characterized as the amount of time it takes for voice to leave 
the source repeater and reach the destination repeater. Three types of delay are inherent in the 
backend networks: 

• propagation delay 

• serialization delay 

• handling delay 

Propagation delay is caused by the distance a signal must travel via light in fiber or as electrical 
impulses in copper-based networks. A fiber network stretching halfway around the world (13, 000 
miles) induces a one-way delay of about 70 milliseconds. 

Serialization delay is the amount of time it takes the source repeater to actually place a packet 
byte by byte onto the backend network interface. Generally, the effect of serialization delay on total 
delay is relatively minimal but since IP Site Connect system sends a voice packet one-by-one to all 
the repeaters, the serialization delay for the last destination repeater is (# of repeaters - 1) times 
the serialization delay for the first destination repeater. 

Handling delay defines many different types of delay caused by the devices (e.g. secure routers) 
that forward the packet through the backend network. A significant component of the handling 
delay is the queuing delay, which occurs when more packets are sent out to a network device than 
the device can handle at a given interval. 

The CPS allows setting the Total Delay (i.e. sum of propagation delay, serialization delay, and 
handling delay) to be High (90 ms) or Normal (60 ms) in both the repeaters and the radios. Note 
that radios also support higher value (500 ms) of total delay, which should not be used in case of 
IP Site Connect system. The default is Normal. This is used to derive values for other parameters 
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such as Arbitration Interval and Call Hang Times in repeaters and Ack Wait times in radios. For 
proper functioning of an IP Site Connect system, all the repeaters and radios should have the 
same delay setting. 

It is recommended that propagation and handling delays between repeaters should be measured 
(e.g. by “pinging”) between all pairs of repeaters. 

The total delay is equal to the maximum of the measured values + (# of repeaters - 1) * (1/2 + 
1000/BW in Kbps) ms, where the BW is the available bandwidth of the backend network. 

If the total delay is less than 60 ms then the setting should be Normal. If the total delay is more 
than 60 ms but less than 90 ms then the setting should be High. The IP Site Connect system will 
not work satisfactorily, with occasional failure of arbitration, hang time and data link layer 
acknowledgements, for a backend network having total delay of more than 90ms. The 
disadvantage of the setting at 90ms is that there is an increase to audio throughput delay. 

4.6. 3.2.2 Jitter 

Jitter is the variation of packet inter-arrival time. The source repeater is expected to transmit voice 
packets at a regular interval (i.e. every 60 ms for one channel). These voice packets can be 
delayed throughout the backend network and may not arrive at that same regular interval at the 
destination repeater. The difference between when the packet is expected and when it is actually 
received is called Jitter. To overcome the effect of jitter, the IP Site Connect system employ a Jitter 
Buffer of fixed 60 milliseconds. If a packet does not arrive at a destination repeater within the 60 
ms after the expected time then the repeater assumes the packet is lost, replays a special erasure 
packet, and discards the late arriving packet. Because a packet loss affects only 60 ms of speech, 
the average listener does not notice the difference in voice quality. Thus, a jitter of more than 60 
ms degrades the audio quality. 

4. 6. 3. 2. 3 Packet Loss 

Packet loss in IP-based networks is both common and expected. To transport voice bursts in 
timely manner, IP Site Connect system cannot use reliable transport mechanisms (i.e. confirmed 
packets) and therefore while designing and selecting the backend network it is necessary to keep 
packet loss to a minimum. The IP Site Connect system responds to periodic packet loss by 
replaying either a special packet (in the case of voice) or the last received packet (in the case of 
data). In the case of voice, the ongoing call ends if six consecutive packets do not arrive within 60 
ms of their expected arrival time. In the case of data, the repeater waits for the expected number of 
packets (as per the data header) before ending the call. 
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4. 6. 3. 2.4 Network Bandwidth Considerations 

Bandwidth is the amount of data transferred to and from a network device, often referred to as the 
bit rate. Bandwidth is measured in bits per second or kilo-bits per second (kbps). When designing 
an IP Site Connect system, it is important to understand the needs of each IP Site Connect device 
so that the appropriately rated network connection for each site can be chosen. 

If a customer has high speed network connections between sites, these calculations may not be 
as important, but if they are working on lower speed public Internet Service Providers (ISPs) it is 
good practice to understand these values and plan accordingly. If the minimum amount of 
bandwidth is not available, the end user may experience audio holes or even dropped calls. Radio 
to Radio Data messaging or RDAC commands may not be successful on the first attempt, or may 
be dropped all together. In general, the quality of service may suffer if substantial bandwidth is not 
available. 

Note that for most Internet Service Providers, the uplink bandwidth is the limiting factor. The 
downlink bandwidth is usually multiple factors above the uplink bandwidth. Therefore, if the uplink 
requirements are met, the downlink requirements are almost always acceptable. Some ISPs may 
state they provide a particular bandwidth, but it is important to verify the promised bandwidth is 
available once the system is installed and throughout operation. A sudden decrease in available 
bandwidth may cause the previously described symptoms. 

It is also important to note that if the wide area network connection is utilized by other services (file 
transfer, multimedia, web browsing, etc.), then the IP Site Connect devices may not have the 
appropriate bandwidth when required and quality of service may suffer. It is suggested to remove 
or limit these types of activities. In addition, overusage of the RDAC application itself may cause 
increased strain on the network during times of High Voice activity. It is recommended that RDAC 
commands be kept to a minimum unless appropriate bandwidth has been allocated. 

4. 6. 3. 2.4.1 Required Bandwidth Calculations 

The amount of bandwidth an IP Site Connect device requires is dependent on a of variety factors. 
The most important factor to understand is that the bandwidth required for one particular device is 
dependent on how many other devices or peers it has in the IP Site Connect system. Equally 
important is the type of devices. Recall that an IP Site Connect system can contain repeaters that 
have two channels operating in wide area, one channel operating in wide area, or no channels 
operating in wide area, such as local channels only. Channels, or slots, operating in local area 
mode do not send their voice traffic over the network. Recall that one repeater within the IP Site 
Connect system acts as the Master. This repeater requires some additional bandwidth. The IP Site 
Connect system may also contain analog repeaters, disabled repeaters, and RDAC applications. 
These devices do not send voice over the network, but they do require the bandwidth to support 
the standard link management and control signaling. 

For a quick reference, the graphs below show the required bandwidth for two simple IP Site 
Connect system configurations. The first shows the required bandwidth for various size systems 
where every repeater in the system utilizes both channels, or slots, as wide area. The second 
shows the required bandwidth for various size systems where every repeater in the system utilizes 
one channel, or slot, as wide area, and the other channel, or slot, as local area. In each system, 
one RDAC is present, repeater authentication is enabled, and Secure VPN is not being utilized in 
the routers. 
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Bandwidth required vs Number of Repeaters 
( 2 Wide Area Channels, with RDAC ) 




Bandwidth required vs Number of Repeaters 
( 1 Wide Area Channel, with RDAC ) 




Number of Repeaters 



Number of Repeaters 



Figure 4-15 Required Bandwidth for Two Simple IP Site Connect System Configurations 



Note that although the two examples above may represent typical IP Site Connect configurations, 
and may provide a quick snapshot of the bandwidth requirements for a particular size system, 
more complicated configurations will require additional calculations. 



The following equation should be used to calculate the bandwidth for each IP Site Connect device 
in the IP Site Connect system, and then added together at sites where multiple devices reside 
behind one wide area connection. 



BW V c = 15 kbps = Bandwidth required to support Wide Area Voice or Data (1 slot) 
BW lm = 6 kbps = Bandwidth required to support Link Management 
BW| R = 3 kbps = Bandwidth required to support Master Messaging 
BW rd = 55 kbps = Bandwidth required to support RDAC commands 
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* Peer does not include self. 



To help demonstrate the use of the above equation on a more complicated IP Site Connect 
system, take the following example system shown in the diagram below. This system has six total 
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IP Site Connect devices at three sites; five repeaters and one RDAC. Three of the repeaters have 
both channels configured as wide area, one has a wide area channel and a local channel, and the 
last repeater has two local channels. The routers are not utilizing Secure VPN. 




Figure 4-16 Example System for Calculating Bandwidth Requirements without Secure VPN 

Let us start with Repeater 1. Repeater 1 is an Master and has two wide area channels. The first 
wide area channel has three peers and the second wide area channel has two peers. Note that 
since Repeater 4 and Repeater 5 have local area channels, these are not considered wide area 
channel peers. It is also important to remember that a peer does not include the device currently 
being calculated. 

Each calculation provides enough bandwidth to support an RDAC command during times of high 
activity. This assumes that only one RDAC command occurs at a time and is not utilized often. If it 
is expected that multiple RDAC applications will be performing commands on repeaters often and 
simultaneously, one might wish to increase the bandwidth to support these types of activities. 

The detailed bandwidth calculation for Repeater 1 is as follows: 
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Using the same method for all IP Site Connect devices in the example system yields the following: 
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* Peer does not include self. 



IP Site Connect devices behind a single router need to be added together to acquire the wide area 
network bandwidth requirements. See the final bandwidth requirements in the figure above. 

Note that an analog repeater or disabled repeater connected to the IP Site Connect system would 
require the same amount of traffic as a local only repeater (Repeater 4). But keep in mind that if 
the disabled repeater will eventually be enabled without disabling a different repeater, the 
bandwidth of the enabled repeater should be accounted for in the bandwidth plan. 
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4 . 6 . 3 . 2 . 4. 2 Required Bandwidth Calculations While Utilizing a Secure 
Virtual Private Network 

As was discussed in previous chapters, peer-to-peer communications over the network are 
optionally authenticated and are also encrypted end-to-end if enabled in the radios. See “Voice 
and Data Privacy” on page 99 If this is not considered sufficient for a particular customer, IP Site 
Connect supports the ability to work through a Secure Virtual Private Network (VPN). Secure VPN 
is not a function of the IP Site Connect device but rather of the router. It is important to note that 
Secure VPN does add the need for additional bandwidth and may introduce additional delay. 

For a quick reference, the graphs below show the required bandwidth for the two previously 
discussed simple IP Site Connect system configurations, but in this case utilizing routers with 
Secure VPN enabled and repeater Authentication Disabled. When utilizing Secure VPN routers, 
repeater authentication is not necessary since the Secure VPN utilizes its own authentication. As 
can be seen, the bandwidth requirements per device increase substantially. This should be taken 
into account when planning for bandwidth. 



Bandwidth Required vs Number of Repeaters 
( 2 Wide Area Channels, with RDAC, Secure VPN ) 




Bandwidth Required vs Number of Repeaters 
( 1 Wide Area Channel, with RDAC, Secure VPN ) 
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The following parameters should be used in the previous equation to calculate the bandwidth 
requirements of each device in the system when secure VPN in the routers is enabled and 
repeater authentication is disabled. 

BWVC = 23 kbps = Bandwidth required to support Wide Area Voice or Data with Secure VPN 
BWLM = 5 kbps = Bandwidth required to support Link Management without authentication 
BWIR = 4 kbps = Bandwidth required to support Master Messaging 
BWRD = 64 kbps = Bandwidth required to support RDAC commands 

NOTE: The preceding data was compiled using the Linksys EtherFast Cable/DSL VPN Router 
with four-port switch. Model: BEFVP41 . Other routers using different algorithms may yield 
different results. 
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4.6.4 Flow of Voice/Data/Control Messages 

The flow of voice/data/control messages from a radio to its repeater for an IP Site Connect 
configuration is the same as that of single-site configuration of MOTOTRBO system. The major 
changes in the flow of messages (between single site operations and multiple site operations) are 
in the processing of a message in the repeaters and the additional delays introduced due to 
reasons such as serialization, propagation, arbitration, and the nonalignment of slots between 
repeaters. This section describes the changes. 

On receipt of a start up of a voice/data/control call from a radio over a slot, a repeater sends it over 
the backend network to all the repeaters that are enabled, operating in digital mode, and the 
corresponding slot is configured for multiple site operation. This implies that at any time at most 
two calls are active in an IP Site Connect system if both slots are configured for multiple site 
operation. 

In an IP Site Connect configuration, calls can start concurrently at more than one repeater and due 
to different messaging delay between repeaters, it is possible that different repeaters select 
different calls for repeating over-the-air. To overcome this problem, on receipt of a start up of a 
voice/data/control call either over-the-air (from a radio) or over the backend network (from other 
repeaters), a repeater starts an arbitration window for a duration of twice the Inter-Repeater 
Messaging Delay. At the end of the arbitration window, the repeater selects one of the calls 
received during this window using a procedure that ensures that all the repeaters select the same 
call. After selection, a repeater starts repeating the bursts of the selected call. A disadvantage of 
the arbitration procedure is that it increases the System Access Time. 

The voice/data/control messages are sent burst by burst between repeaters. Like a single-site 
system, a repeater does no data link layer processing (e.g. acknowledgement, decryption). If 
required, the voice and data messages are encrypted-/-decrypted by the source and destination 
radios. A repeater sends the voice or data packet to other repeaters as it receives over-the-air. 
Also in case of data message, the destination radio sends the Ack/Nack and if required the 
Selective ARQ takes place between the source and destination radios and not between a radio 
and its repeater. 

A call is a session of one or more transmissions from participating radios. To ensure continuity 
between transmissions, the single site configuration of MOTOTRBO has Hang Time, during which 
the channel is reserved for participant(s) of the ongoing call. The IP Site Connect configuration 
extends the concept of session to include Remote Monitor call, Individual and group data call, and 
CSBK Call (e.g. Call Alert, Radio Check, Inhibit/Uninhibit). The Hang Time ensures that a call 
continues with minimum interruptions. 

The flow of data messages from a radio to an application (e.g. Location or Text Messages) in an IP 
Site Connect system is similar to a single-site configuration of MOTOTRBO. A data packet flows 
burst-by-burst to a Control Station connected to the Application Server. The Control Station 
assembles the bursts into a PDU. If the PDU is confirmed then the Control Station handles the 
data link layer acknowledgement. If the PDU is encrypted then the Control Station decrypts the 
PDU. The Control Station strips the data link layer headers and forwards the resulting datagram to 
the Application Server. 
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All the data applications of the single site configuration of MOTOTRBO are compatible with IP Site 
Connect configuration. An IP Site Connect configuration supports the revert channels, where a 
revert channel can be a channel of another IP Site Connect system. The GPS data on a GPS 
Revert Channel are sent unconfirmed in IP Site Connect mode. This increases the throughput of 
the GPS data as the data link layer acknowledgement over the backend network is slower due to 
delays associated with the backend network. 

4.6.5 Security Considerations 

The single site configuration of MOTOTRBO offers two types of privacy mechanisms over-the-air- 
Basic Privacy and Enhanced Privacy. See “Voice and Data Privacy” on page 99. The IP Site 
Connect configuration not only supports both mechanisms, but also extends them over the 
backend network. A repeater does not decrypt the encrypted packets. It simply passes the packets 
as received over-the-air to other repeaters. Since the two mechanisms are not compatible, all the 
radios and repeaters of an IP Site Connect system should support the same privacy mechanism. 
This should be ensured during configuration. Note that the privacy mechanisms protects only the 
voice or data payloads. They do not protect the voice or data headers, or control messages (i.e. 
CSBK) or system messages (between repeaters). 

An IP Site Connect system optionally offers authentication of all the packets sent between IP Site 
Connect devices. Each packet has a 10 bytes long cryptographic signature. The signature is 
created using Keyed-Hash Message Authentication Code (HMAC), which is a National Institute of 
Standards and Technology (NIST) standard. The hashing is done using SHA-1 algorithm. The 
HMAC uses a 20 bytes long symmetric keys and generates a 20 bytes long signature. To reduce 
the bandwidth requirement over the backend network, the 20 bytes long signature is truncated to 
10 bytes before attaching to the packet. Packet authentication prevents an attacker from using an 
impersonator as an IP Site Connect device in order to get access to the IP Site Connect system. 
This feature, if selected by a customer, requires the customer to manually configure the same key 
to all the IP Site Connect devices. Note that the IP Site Connect system does not support rekeying 
remotely. 

The above authentication mechanism does not provide protection against the replay attacks. For a 
more secure authentication, an IP Site Connect configuration should use Secure VPN routers to 
connect with the backend network. Secure VPN routers can optionally provide confidentiality of all 
the messages including system messages (between IP Site Connect devices), control messages 
(i.e. CSBK), and voice or data headers. A disadvantage of using Secure VPN Routers is that the 
IP Site Connect requires more inbound and outbound bandwidth from the ISP. The use of Secure 
VPN routers make the authentication mechanism of IP Site Connect redundant and it is 
recommended that it should be disabled. This saves some bandwidth over the backend network. 
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4.6.6 General Considerations When Setting Up the Network 
Connection for an IP Site Connect System 

Network setup and configuration varies significantly depending on the complexity of the equipment 
and IP network the system resides on. It is always wise to communicate with the Network 
Administrator during installation and during the design phase as they are likely be the individuals 
configuring the network equipment and own a great deal of knowledge in this area. Below is a 
short list of items to keep in mind when setting up or when troubleshooting the networks of IP Site 
Connect systems. 

• When assigning Static IP addresses within a Network, it must not conflict with another 
static IP address. As with any IP conflict, this can cause a disruption to the IP Site 
Connect traffic. Also, ensure that the static IP address does not fall into the DHCP 
assignable range. This can cause an IP conflict if the address is dynamically assigned to 
another device on the network. 

• If other network devices are present on the same IP network as the IP Site Connect 
devices, it is good practice to setup Quality of Service (QoS) rules in the Internet Router. 
This ensures that the IP Site Connect packets have priority over other traffic on the 
system. Not doing this could cause audio performance degradation or lost transmissions 
when other devices on the system are excessively utilizing the network. There are 
various methods routers use to provide QoS. It is commonly performed by configuring a 
range of UDP ports or IP Addresses a specific amount of upstream and downstream 
bandwidth. The default UDP port for IP Site Connect is 50000. For details on calculating 
the required bandwidth, see section “Required Bandwidth Calculations” on page 312. 

• Verify that the customer network equipment is not blocking the IP Addresses or UDP 
Ports (default 50000) utilized by the IP Site Connect system. This is commonly done by 
a firewall or other security device. Consult the customer’s Network Administrator or 
Internet Service Provider. 

• Inquire with the Internet Service Provider if there are any caps on bandwidth usage per 
month. Some ISPs do not allow the customer to exceed a particular upload or download 
limit per month. Since IP Site Connect systems stream voice over the internet, it may be 
possible to surpass this limit on extremely high usage systems. As a reference point, a 
five site system under nominal load could use around 20GB per month, where as a 15 
site system under nominal load could use around 65GB per month. For most ISPs, this 
will not be an issue. 

• When configuring routers with VPN links, it is wise to increase the IPSec Key Life Time 
(KLT) Timers to around 13 to 24 hours. It is recommended to set Phase 1 KLT to 24 
hours, and Phase 2 KLT to 13 hours. Some low-end routers cause a disruption to 
ongoing voice and data when renegotiating keys after the Key Life Time Timer expires. 
This is especially noticeable when multiple VPNs are configured with identical Key Life 
Time Timers since the router will need to re-calculate numerous keys at the same time. 
It is best practice to offset each VPN’s Key Life Time Timers by 10 minutes. 
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4.6.7 Considerations for Shared Use of a Channel 



To take care of shared use of a physical channel, a repeater (e.g. green repeater) of an IP Site 
Connect system always monitor its Rx frequency and does not transmit if the Received Signal 
Strength Indicator (RSSI) from radio(s) of some other radio system is greater than a configurable 
threshold. This ensures that an IP Site Connect system will not use a channel if another repeater, 
in vicinity, is currently using the channel. The RSSI threshold is CPS programmable in the range of 
40 dB to 130 dB. The threshold should be chosen wisely otherwise interference from background 
noise may inhibit a repeater from transmitting. The RDAC application can be used to measure the 
inbound RSSI of an interfering signal if required. 

The figure below shows the transmission of red radio interfering with the green repeater. 




Figure 4-17 An Example of Interference at Receive Frequency 
The above monitoring scheme of Rx frequency is not sufficient in the following conditions: 

• In VHF range, in some countries (including USA), the transmit frequency is not tightly 
bound to a receive frequency 

• There is no radio in the other radio system that is currently using the system. 

• The other radio system is being used by a console. 

• The radio that is using the other radio system is too far from the IP Site Connect system. 

To take care of above conditions, it is recommended that a repeater of an IP Site Connect system 
should use an external RF receiver. The external RF receiver is tuned to the transmit frequency of 
the repeater and activates a GPIO compatible output when it receives RF signal. The output of the 
receiver is connected to the “Transmit Inhibit” (an input GPIO line) of the repeater. The repeater 
does not wake up if its “Transmit Inhibit” line is active. An attenuator can be inserted between the 
antenna and the receiver, if it is required to change the threshold of the received signal. The net 
effect of this configuration is that the repeater does not wake up if there is another repeater 
transmitting at its Tx frequency. The repeater CPS allows its user to associate an input line of the 
GPIO lines with “Transmit Inhibit”. This arrangement is also applicable to single-site repeaters. 
The figure below shows the transmission of red repeater interfering with the green repeater. 
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Figure 4-18 An Example of Interference at Transmit Frequency 

4.6.8 Migration from Single Site Systems 

The hardware of radios (both portables and mobiles) and repeaters of MOTOTRBO’s single site 
system are fully compatible with the IP Site Connect configuration. To migrate to IP Site Connect 
system the customer is required to update the software of repeaters and reconfigure them. Some 
of the features of the single site radios may work in the IP Site Connect system but it is highly 
recommended that the software of the radios should also be updated. Data applications of single 
site configuration are fully compatible with the IP Site Connect configuration. 
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4.6.9 Migration from an Older IP Site Connect System 

IP Site Connect repeaters provide a robust migration for upcoming software versions for 
repeaters. IP Site Connect repeaters exchange their respective link protocol version information 
and validate interoperability support when they detect repeaters having different firmware/software 
versions loads. 

Example: Assume an IP Site Connect system running on software version R01.05.00 is being 
upgraded to R01.06.00. The upgraded R01.06.00 repeater initiates the discovery, 
exchanges link protocol version information with the R01.05.00 repeaters, and 
synchronizes the protocol versions for optimal repeater operations. 

While the repeater’s versioned IP link protocol provides a clean migration methodology between 
repeater software versions, there are limitations associated with this feature. Repeaters support 
the current and previous two releases. Hence, repeater operations and interoperability beyond the 
previous two releases would result in incompatibility between repeaters. In such abnormal 
scenarios, customers are required to upgrade the system such that all repeaters operating on the 
system remain compatible; meets the requirement of the current and previous two releases. 

A service degradation is expected in scenarios that include multiple repeater firmware versions 
running in the system. Therefore, usage of the same repeater firmware version throughout the 
system, and only allow usage of different firmware versions during the upgrade period is preferred. 

The IP Site Connect repeaters discover each other through the Master repeater (configurable via 
the CPS); which is a centralized entity of the system. The recommendation is to have the Master 
repeater upgraded first to minimize system downtime, optimize IP link connectivity and improve 
system access time across the backend IP network. 





System Design Considerations 



323 



4.7 Multiple Digital Repeaters in Capacity Plus 

The main problem with the standalone configuration of multiple digital repeaters is that a radio can 
only use one channel of a repeater at any instance of time. Capacity Plus resolves this restriction 
and allows a radio to use all the repeaters at a site. The sharing of repeaters improves the 
utilization of channels. 

4.7.1 System Capacity 

In Capacity Plus, from software version R02.30.00 onwards, MOTOTRBO supports a maximum of 
20 backend network devices (e.g. repeaters, RDAC PC), where network devices include a 
maximum of eight trunked repeaters (i.e. sixteen Trunked Channels), twelve Data Revert 
repeaters (i.e. 24 revert channels), and five RDACs or similar applications. 

A Capacity Plus channel mode supports more radios compared to a single repeater configuration 
(for details, see “Estimating Loading (For Capacity Plus)” on page 287). The ID of radios in 
Capacity Plus ranges from 1 to 65535 (i.e. 16 bit) and the ID of groups in Capacity Plus ranges 
from 1 to 254 (i.e. 8 bit). The Group ID of 255 is reserved for All Call. 

When adding a new trunked repeater to a Capacity Plus system, all the radios should be 
configured with the channels of the new repeater, before the new repeater is connected to the 
Capacity Plus system. 

4.7.2 Frequencies and Color Code Considerations 

As Capacity Plus is a single site trunking system, all the repeaters should use different 
frequencies. Their color code can be the same or different. A Capacity Plus system has the ability 
to share RF channel(s) with other systems, but it is necessary to ensure that all channels in all 
overlapping systems have a unique frequency pair and color code combination. 

A Capacity Plus radio requires lists of all trunked and revert channels. This makes it necessary to 
reprogram all the radios when a frequency is added to the system. If a Capacity Plus system is to 
be expanded in the future, and if these frequencies are known, then it is recommended to keep all 
future frequencies in the trunked list. Keeping additional trunked frequencies in the radio 
marginally slows down the radio operations when the radio is powered on, or when the radio 
comes out of fade. But this prevents the need to reconfigure all the radios when new repeaters are 
added. 

If a Capacity Plus repeater needs to be removed from service for an upgrade or for repair, there is 
no need to reconfigure the radios. The MOTOTRBO Capacity Plus system can still operate as long 
as there is one Capacity Plus repeater functioning in the system. Additionally, there is no need to 
power down the whole MOTOTRBO system while removing or adding a repeater in the Capacity 
Plus system. 

The above recommendation is also true for revert channels but with a condition. A radio may 
experience delay in transmitting data over revert channels. During this delay, a radio may miss a 
call taking place on the Trunked Channel. 
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4.7.3 Considerations for the Backend Network 



A Capacity Plus system requires a backend network if it has more than one repeater. The backend 
network for Capacity Plus is a Local Area Network. In the simplest and most common 
configuration, an Ethernet Switch is used to connect all repeaters. To add a remote RDAC, or the 
MNIS, connect the Ethernet Switch to a Router that supports hair-pinning (see section 3. 2. 4. 1.4 for 
a list of recommended devices). This router is connected to either a dedicated network, or to the 
Internet (provided by an Internet Service Provider). Although Capacity Plus works with most off- 
the-shelf devices, the following Ethernet Switch is suggested for use. 

• HP Procurve - 2530-24 (J9782A) 

• Router - HP MSR 20-20 

A repeater has three network interfaces: Ethernet, USB, and over-the-air. A repeater uses its 
Ethernet port to communicate with other network devices using IPv4/UDP. Since UDP does not 
support confirmation, Capacity Plus provides its own acknowledgement and retry mechanism for 
critical activities. The Ethernet port is not the default IP gateway of the repeater. An IP datagram 
that arrives from USB or from over-the-air is not automatically routed to the Ethernet port. 

Only the Master repeater needs a static IPv4 address. Other Capacity Plus devices may have 
either static or dynamic IPv4 addresses. Dynamic IPv4 addresses are allocated by a DHCP 
server. The dynamic IPv4 addresses may change every time the Capacity Plus device powers-on 
or periodically (every few hours). To enable the use of dynamic addresses, select the DHCP option 
in the repeater codeplug via the CPS. The lease time of the IPv4 address from the DHCP server 
should be kept as long as possible. A change in the IPv4 address of a device causes a short 
disruption of service. To enable the use of static IPv4 addresses, do not select the DHCP option; 
ensure the static IPv4 address, the gateway IPv4 address and netmask are provided. 

Just like an IP Site Connect configuration, a Capacity Plus configuration uses “Link Management” 
to keep a device aware of the status, the current IPv4 address, and UDP port of other devices. For 
reference, see “Considerations for the Backend Network” on page 308 on Link Management in an 
IP Site Connect configuration. The Link Management requires only one of the repeaters (called a 
Master) to act as a broker of IPv4/UDP addresses. The Master’s IPv4/UDP address is configured 
into all the Capacity Plus devices. The Master’s IPv4/UDP address refers to its address as seen 
from the backend network. A firewall/NAT may translate the address in the customer network into 
another address on the backend network. 

4.7.4 Behaviors in Presence of Failures 



A Capacity Plus system has no centralized controller and this makes it tolerant to failures. It 
automatically detects most types of failures, reconfigures itself, and continues to provide the 
services although with decreased capacity. 

A repeater detects the failure of other repeaters or the backend network. “Keep Alive” messages 
are periodically exchanged between repeaters. The absence of such messages from a repeater 
indicates a failure of either that repeater or of the network in between. A failed repeater is not 
selected as a Rest Channel repeater. If a Rest Channel repeater fails, a new Rest Channel is 
selected by the system. 

To help a radio detect the failure of the Rest Channel repeater, the Rest Channel repeater 
periodically broadcasts system status over the Rest Channel. If a radio misses the broadcast, then 
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it knows that either the repeater has failed or it is not within the coverage area of the repeater and 
the radio starts searching for the Rest Channel. 

When the backend network switch fails, each repeater cannot connect to all other repeaters. Each 
repeater then starts working as a two-channel trunking system. At the time of the switch failure, all 
radios may be on the Rest Channel or busy on other channels. In the first instance, the call 
capacity is severely impacted while in the second, radios on different channels are unable to 
communicate. 

To resolve a failure of a revert channel repeater, a radio makes multiple attempts to transmit a data 
message on different channels. 

If a Trunked Control Station fails, a set of radios will not receive data messages from the 
Application Server. 

4.7.5 Adaptive Rest Channel Rotation (ARCR) 

Starting with software version R02.40.00 onwards, LCP and Capacity Plus System supports 
ARCR functionality. The ARCR functionality provides resilience to rarely occurring fault 
mechanisms that can occur in trunked systems and therefore applies to LCP and Capacity Plus 
systems only. The functionality ensures that a rest channel is available even in the presence of 
very specific adverse channel conditions and protects the system in the event of certain types of 
rarely occurring hardware failures. 

The functionality adds additional resilience in the following scenarios: 

• Co-channel interference on the uplink that is below the System RSSI detect threshold 
configured in a repeater but high enough to prevent the repeater from receiving all 
radios call request. A subset of the above includes the deployment where, 

• The ‘System RSSI' detect threshold is intentionally set high to lower the 
likelihood of “losing” channel (i.e., have it temporarily taken out of the trunk 
pool) due to a co-channel licensee’s activity, i.e., it is set intentionally high to 
“tolerate” the negative effects of simultaneous co-channel use, albeit with 
some negative side effects on range performance. 

• The System RSSI threshold isn’t set or isn’t set properly. 

• Previously unknown/unanticipated co-channel interference occurring after 

commissioning due to a co-channel license being granted. 

• Failures in the receiver line-up of a repeater, including: 

• Receiver antenna issues (e.g., broken, damaged, etc.) 

• Receiver transmission line issues, 

• Receiver antenna distribution network issues, 

• Receiver hardware failure 

• Inter-modulation (IM) Products: 

• Previously unknown/unanticipated interference due to a frequency being 
granted which results in an undesirable inter-modulation product 

• Sites which use multiple antennas, potentially as many as 2 antennas (Tx and 
Rx) per repeater at a site (e.g., a large rooftop installation to provide sufficient 
separation between antennas, while saving the cost and complexity of a 
combining network). 
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• Operation in densely populated and changeable RF environments. 

With ARCR functionality, a site of a system will continue to operate and allow communication with 
other working channels (Repeater and the Hardware links) as long as there are working external 
RF links, Hardware links, and Repeaters on the site. 

In nutshell, the ARCR functionality forces a rest channel to automatically move to another channel 
if there is no incoming call on the rest channel for a specific duration. The duration is adaptively 
changed, based on the volume of incoming calls. To ensure a guaranteed rest channel rotation in 
all call volume conditions, the duration is limited between a minimum time that is equal to a ‘SIT + 
a beacon duration’ time and the maximum time which can be set via the CPS ‘Rest Channel TOT' 
field. For proper operation, the Rest Channel TOT value must be same on all the repeaters of a 
site. 

Guidelines for choosing Rest Channel TOT: 

1 The Rest Channel TOT will be most effective during idle or low call volume 
condition. For the site where the repeaters have different channel preference 
level, it is suggested to use larger Rest Channel TOT value, so that high- 
preference channels are more frequently utilized even during low call volume 
conditions. Note that the force rest channel mechanism steers the rest 
channel through all preference level repeaters in round-robin manner, whereas 
the incoming calls mechanism selects higher preference channels more often 
than lower preference channels. 

2 Shorter Rest Channel TOT will lead to faster Rest Channel rotation and better 
resilience to the failure, however may have minor impact to battery life, 
because radios will receive new rest channel assignment information more 
often. 

3 The Rest channel rotation may cause minor delay in call access time during 
force rest channel switching period. The Faster the rotation, the more frequent 
will be such access time delays. Note the impact of such delays should be 
unnoticeable to radio users. 

4 If necessary, the ARCR functionality can also be disabled completely by 
disabling Rest Channel TOT value. 

If a rest channel assignment is repeatedly force rotated from a specific repeater, while all other 
channels rotate as rest channels due to normal radio calls, the software algorithm will suspect that 
the particular channel has failed and will reduce its rest channel preference to the lowest level. 
Consequently, that suspected repeater will be utilized less, to minimize the likelihood of a rest 
channel becoming unavailable on that repeater and blocking system access. In due course, if a 
suspected repeater is found to be working then the preference level is reverted back to the 
configured level. 

4.7.6 Limiting Interference to Other Systems 

Capacity Plus is designed to be compatible with both exclusive and shared channels. To help a 
radio detect the unavailability of a Rest Channel, the repeater periodically transmits a very short 
system status message beacon. If the radio misses this transmission on a Rest Channel, then the 
radio is either not within the coverage area of the repeater or the repeater cannot transmit (due to 
interference by other systems or a failure). The radio then starts searching for a new Rest 
Channel. The interval of periodic transmissions of the system status messages can be selected 
within certain limits by an authorized technician. There are two points to consider: 





System Design Considerations 



327 



• A more frequent beacon transmission helps a radio detect the unavailability of the Rest 
Channel faster, and thus reduces the downtime caused by interference from other 
systems and improves capacity. Hence, it is recommended to keep the beacon interval 
at the default value. 

• If the system incorporates a shared channel causing interference to other systems, the 
default value of the beacon interval can be increased. 

4.7.7 Plan for Talkaround Mode 

In Capacity Plus, a MOTOTRBO radio does not support Talkaround. To ensure a communication 
channel is available when the Capacity Plus system is completely shut down or when a radio has 
moved out of the coverage area, it is recommended to program at least one common channel in 
Talkaround mode, i.e. at least one of the channel knob position should be programmed for 
Talkaround mode. 

The Talkaround mode configuration is useful when the Capacity Plus system fails or the radio is 
out of coverage area. All that a user needs to do is to switch to Talkaround personality. 

The radio user may define their own protocol for when to switch to Talkaround mode. For example, 
all radio users may switch to Talkaround mode when their radio is not on the Capacity Plus system 
for more than 10 minutes. 

A customer may decide to plan the Talkaround mode configuration according to the number of 
groups that need such an operation. The available Talkaround mode frequencies should be 
distributed to the different groups based on their call profiles. Radios users can use scan mode in 
Talkaround. 

To detect if the Capacity Plus system is once again up and running, radio users may periodically 
switch to a Capacity Plus channel and observe the activity on the channel. 

4.7.8 Ways to Improve Battery Life 

To improve battery life of a portable radio, a user can switch the radio power to low power mode by 
using the radio menu or power button. Low power mode improves battery life of a portable radio 
significantly over the high power mode. 

When a user notices that the radio is not providing talk-permit tone for multiple PTT attempts in low 
power mode and that the signal strength bar is still visible, the radio should be switched to high 
power mode when initiating a call. When switching to different power modes, the radio user will not 
miss any incoming calls. The call listening capability of radio does not change with the radio 
transmit power. 

Additionally, a radio user may turn off the radio when calls are not expected or when the radio is 
out of coverage. 

4.7.9 MOTOTRBO Telemetry Connection Details 

For more details about the telemetry GPIO pin assignments, please refer to the MOTOTRBO 
Telemetry ADK Guide available on the MOTODEV Application Developers website. 
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4.7.10 Considerations for Configuring Combined Firmware Versions 

In cases where legacy repeaters and other higher versions of repeaters needs to be connected 
together, it is highly recommended to make one of the higher version repeaters as the Master 
repeater, to avoid service degradation issues. 

In scenarios where the MTR3000 repeaters are combined with the MOTOTRBO repeaters, it is 
possible that the MOTOTRBO repeater firmware is of a higher version than the MTR3000 repeater 
firmware. Configure the MOTOTRBO repeater as the Master repeater to avoid service degradation 
in this scenario. 

4.7.11 Upgrading from Capacity Plus 

Repeaters running on software version RR02.30.00 or later are not interoperable with repeaters 
running on software version prior to R02.30.00. Hence, if there is a repeater with software version 
R02.30.00 or later present in a Capacity Plus system, all the other repeaters will have to be 
upgraded to R02.30.00 or later altogether. 

When upgrading a Capacity Plus system, upgrade the Master first, followed by all other repeaters 
at the site. During the upgrade, the Capacity Plus system acts as two mutually exclusive systems, 
but calls are still supported. All radios should remain tracking the legacy system until the last 
legacy repeater is switched off and upgraded, radios will then find the new system and operate as 
normal. 
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4.8 Multiple Digital Repeaters in Linked Capacity Plus 

4.8.1 System Capacity 

In a Linked Capacity Plus configuration, from software version R02.30.00 onwards, MOTOTRBO 
supports up to 15 sites, including host PCs, and a maximum of eight trunked repeaters per site. 
For the data revert repeaters at a site, up to 11 can be supported. However, the number of trunked 
repeaters plus the number of data revert repeaters must not exceed a total of 12. For example, if 
there are eight trunked repeaters at a site, only up to four data revert repeaters can be supported 
at that site. 

A Linked Capacity Plus system supports more radios per channel compared to a single repeater 
configuration or IPSC configuration. This is based on the following reasons: 

• A customer can configure a talkgroup as a local talkgroup. The local talkgroup call is 
transmitted over-the-air at only one site. 

• A customer can associate a set of sites with a talkgroup. The talkgroup call is 
transmitted over-the-air at only the associated sites. 

• After initial handshakes, a Private Call is transmitted at either one or two sites only. 

The radio and talkgroup IDs in Linked Capacity Plus are the same as the IDs in Capacity Plus. The 
ID of radios in Linked Capacity Plus ranges from 1 to 65535 (that is, 16-bit) and the ID of 
talkgroups in Linked Capacity Plus ranges from 1 to 254 (that is, 8-bit). The Group ID of 255 is 
reserved for All Call. 

When adding a new trunked repeater to a Linked Capacity Plus system, all radios should be 
configured with the channels of the new repeater before the new repeater is connected to the 
system. 

4.8.2 Considerations for Frequencies, Color Code, and Interference 

In a Linked Capacity Plus system, the frequencies and color code of repeaters should satisfy the 
following rules: 

• All the repeaters at a site should use different frequencies. Their color code can be the 
same or different. 

• If the system incorporates a shared channel, then the beacons cause interference to 
other systems. In such scenarios, the value of the beacon interval can be increased. 

• The repeaters of the non-adjacent sites of a Linked Capacity Plus system should use 
different frequencies and color code combinations. It is not advisable to keep the same 
frequencies and color code because a roaming radio is not able to distinguish between 
them, and may use incorrect Data Revert Channels or an incorrect list of neighboring 
sites. 

• A Linked Capacity Plus system can share one or more of its channels with other 
systems. However, it is necessary to ensure that all the overlapping channels of different 
systems have a unique frequency and color code combination. If the frequencies of the 
geographically adjacent repeaters of two systems are the same, then their color codes 
should be different. It is not advisable to keep the same frequencies because in areas of 
overlap, destructive interference can occur. 
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• A system may be sharing the channels with other systems over multiple sites. It is 
possible that two systems (named here as Sysl and Sys2) may be using the same 
(frequencies, color code) pair at two different sites (for example, Sitel and Site2). 
During automatic site search, a Sysl radio at Site2 finds a Sys2 repeater and stays on 
that channel. This is not a desirable situation. One way to avoid this situation is to 
ensure that all the (frequencies, color code) pairs of all the overlapping systems are 
unique. 

To take care of shared use of a physical channel, an LCP repeater always monitors its Rx 
frequency and does not transmit if the RSSI from radio(s) of some other systems is greater than a 
configurable threshold. This ensures that an LCP system does not use a channel if another 
repeater in the vicinity, is currently using the channel. The RSSI threshold is CPS programmable in 
the range of -40 dBm to -130 dBm. The threshold value should be chosen wisely. A value lower 

than the background noise, inhibits a repeater from transmitting due to interference from 

background noise. A value higher than the RSSI of the radio of some other system makes the 
system unfriendly to systems sharing the frequency. The RDAC application can be used to 
measure the inbound RSSI of an interfering signal, if required. 

The above Rx frequency monitoring scheme is deficient if the LCP repeater is unable to deduce 
that an interfering signal is present on its outbound channel based on the presence of an 
interfering radio transmission from another radio system on its inbound channel. This situation 
may arise for any of the following reasons: 

• There is no tight correlation between the Tx and Rx frequencies (as is the case for 
example in the US VHF band). 

• There is no radio in the other radio system that is currently using the system. 

• The other radio system is being used by a console. 

• The radio that uses the other radio system is too far from the Linked Capacity Plus 

system. 

To take care of the above conditions, it is recommended that a repeater of an LCP system should 
use an external RF receiver. The external RF receiver is tuned to the Tx frequency of the repeater 
and activates a GPIO compatible output when receiving a RF signal. The output of the receiver is 
connected to the “Transmit Inhibit” (an input GPIO line) of the repeater. The repeater does not 
wake up if its “Transmit Inhibit” line is active. An attenuator can be inserted between the antenna 
and the receiver, if it is required to change the threshold of the received signal. The net effect of 
this configuration is that the repeater does not wake up if there is another repeater transmitting at 
its Tx frequency. The repeater CPS allows the user to associate an input line of the GPIO lines 
with “Transmit Inhibit”. This arrangement is also applicable to single site repeaters. 

Linked Capacity Plus is designed to be compatible with both exclusive and shared channels. To 
help a radio detect that it is out of range of its repeater and to facilitate automatic roaming by the 
radio, the repeater periodically transmits a very short beacon. If the radio misses this transmission 
on a Rest Channel, then the radio is either not within the coverage area of the repeater, or the 
repeater cannot transmit (for example, due to interference by other systems or a failure). The radio 
then starts searching for a new Rest Channel. The interval of periodic transmissions of the beacon 
can be selected within certain limits by an authorized technician. There are two points to consider: 

• A more frequent beacon transmission helps a radio detect the “out of range” state faster, 
and thus reduces the downtime caused by interference from other systems and 
improves capacity. Hence, it is recommended to keep the beacon interval at the default 
value. This also makes the roaming faster. 
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• If the system incorporates a shared channel causing interference to other systems, the 
default value of the beacon interval can be increased. 

4.8.3 Considerations for the Backend Network 



In a Linked Capacity Plus system, the repeaters at a site are connected over a LAN. The repeaters 
at a site must be plugged into a switch that must be behind a router because LCP uses locally 
administered IP addresses. The router must support “NAT” 1 . In NAT, internal UDP/IP addresses 
are translated to external UDP/IP addresses. In the simplest and most common configuration, an 
Ethernet switch with a router is used to connect all the repeaters at a site. Although Linked 
Capacity Plus works with most off-the-shelf network devices, the following Ethernet switch and 
router are suggested for use. 

• Switch - HP Procurve 2510-24 (J9019B) 

• Router - HP MSR 20-20 

An LCP repeater uses IP Limited Broadcast Address (255.255.255.255) to distribute a message to 
all the repeaters at a site. The broadcast messages may have some adverse effects on the other 
devices present on the LAN. Therefore an LCP configuration expects that only the LCP repeaters 
are present on the LAN. This router is connected to either a dedicated network, or to the internet 
provided by an ISP. 

Only the Master repeater needs a static IPv4 address. Other repeaters may have either static or 
dynamic IPv4 addresses. The dynamic IPv4 addresses may change every time the network device 
powers-on or periodically every few hours. The lease time of the IPv4 address should be kept as 
large as possible. A change in the IPv4 address of the network device causes a short disruption of 
service. 

Just like an IP Site Connect configuration, a Linked Capacity Plus configuration uses “Link 
Management” to keep a device aware of the status, the current IPv4 address, and UDP port of 
other repeaters. The Link Management requires only the Master repeater to act as a broker of 
IPv4/UDP addresses of repeaters. The Master’s IPv4/UDP address is configured into all the 
Linked Capacity Plus devices. The Master’s IPv4/UDP address refers to its address as seen from 
the backend network. A firewall/NAT may translate the address in the backend network into 
another address in the customer network. The backend network can be a dedicated network or an 
internet. ISPs provide a range of technologies such as DSL (typically ADSL), cable modem, 
broadband wireless access, Canopy, ISDN, Frame Relay, and more. In some cases, dedicated 
links or networks can be effectively used or deployed, removing the monthly fees associated with 
public networks. The backend network cannot be based on dial-up connection (due to small 
bandwidth) or Satellite Internet access (due to large delay). 

A Linked Capacity Plus device registers its IPv4/UDP address during power-on and periodically 
with the Master. The Master then notifies all the devices whenever the IPv4 address of a device 
changes. The devices may be behind firewalls. For successful communication between two 
devices (for example, R1 and R2), the firewall of R1 must be open for messages from R2 and vice 
versa. Since the IPv4/UDP address of an IP Site Connect device is dynamic, it is not possible to 



1. Basic NAT provides translation for IP addresses only, and places the mapping into a NAT table. In other 
words, for packets outbound from the private network, the NAT router translates the source IP address 
and related fields; for example, IP, UDP, and ICMP header checksums. For inbound packets, the NAT 
router translates the destination IP address and related checksums for entries found in its translation 
table. 
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manually configure the firewalls. The Link Management procedure overcomes this problem by 
periodically sending a message from R1 to R2 and vice versa. On a receipt of an outbound 
message (for example, from R1 to R2), the Rl’s firewall keeps itself open for a short duration of 
approximately 20 seconds for an inbound message from R2. A device sends the dummy message 
to another device only if they are parties to the same call. 

Network setup and configuration varies significantly depending on the complexity of the equipment 
and IP network the system resides on. It is always wise to communicate with the Network 
Administrator during installation and during the design phase as they are likely to be the 
individuals configuring the network equipment and own a great deal of knowledge in this area. 
Below is a short list of items to keep in mind when setting up or when troubleshooting the networks 
of a Linked Capacity Plus system. 

• When assigning static IP addresses within a network, it must not conflict with another 
static IP address. Conflicting IP addresses can cause a disruption to the traffic. 
Additionally, ensure that the static IP address does not fall into the DHCP assignable 
range. This can cause an IP conflict if the address is dynamically assigned to another 
device on the network. 

• If other network devices are present on the same backend IP network, it is good practice 
to setup Quality of Service (QoS) rules in the internet router. This ensures that the 
Linked Capacity Plus packets have priority over other traffic on the system. Failure in 
doing this could cause audio performance degradation or lost transmissions when other 
devices on the system are excessively utilizing the network. There are various methods 
routers use to provide QoS. It is commonly performed by configuring a range of UDP 
ports or IP addresses a specific amount of upstream and downstream bandwidth. The 
default UDP port for Linked Capacity Plus is 50000. 

• Verify that the customer network equipment is not blocking the IP addresses or UDP 
ports utilized by the Linked Capacity Plus system. This is commonly done by a firewall 
or other security devices. Consult the customer’s Network Administrator or ISP. 

• Inquire with the ISP if there are any caps on bandwidth usage per month. Some ISPs do 
not allow the customer to exceed a particular upload or download limit per month. Since 
Linked Capacity Plus systems stream voice over the internet, it may be possible to 
surpass this limit on extremely high usage systems. 

• When configuring routers with VPN links, it is wise to increase the IPSec Key Life Time 
(KLT) timers to approximately 13 to 24 hours. It is recommended to set Phase 1 KLT to 
24 hours, and Phase 2 KLT to 13 hours. Some low-end routers cause a disruption to 
ongoing voice and data when renegotiating keys after the KLT timer expires. This is 
especially noticeable when multiple VPNs are configured with identical KLT timers since 
the router needs to re-calculate numerous keys at the same time. It is best practice to 
offset each VPN’s KLT timers by 10 minutes. 

4.8.3. 1 Backend Network Characteristics 

To create a proper backend network design, it is important to know its characteristics. Section 
4. 6. 3. 2 explains the issues dealt with in the backend network of an IP Site Connect system. They 
are also applicable to the backend network of a Linked Capacity Plus system. 

4. 8. 3. 2 Backend Network Bandwidth Considerations 

Bandwidth is the amount of data transferred to and from a network device, often referred to as the 
bit rate. Bandwidth is measured in bits per second or kilobits per second (kbps). When designing 
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an IP Site Connect system, it is important to understand the needs of each IP Site Connect device 
so that the appropriately rated network connection for each site can be chosen. 

If a customer has high speed network connections between sites, these calculations may not be 
as important, but if they are working on lower speed public ISPs, it is good practice to understand 
these values and plan accordingly. If the minimum amount of bandwidth is not available, the end 
user may experience audio holes or even dropped calls. Radio-to-radio data messaging or RDAC 
commands may not be successful on the first attempt, or may be dropped all together. In general, 
the QoS may suffer if substantial bandwidth is not available. 

For most ISPs, the uplink bandwidth is the limiting factor. The downlink bandwidth is usually 
multiple factors above the uplink bandwidth. Therefore, if the uplink requirements are met, the 
downlink requirements are almost always acceptable. Some ISPs may state they provide a 
particular bandwidth, but it is important to verify the promised bandwidth is available throughout 
the operation and once the system is installed. A sudden decrease in available bandwidth may 
cause the previously described symptoms. 

If the WAN connection is utilized by other services (file transfer, multimedia, web browsing, etc.), 
then the IP Site Connect devices may not have the appropriate bandwidth when required and the 
QoS may suffer. It is suggested to remove or limit these types of activities. Additionally, overusage 
of the RDAC application itself may cause increased strain on the network during times of High 
Voice activity. It is recommended that RDAC commands be kept to a minimum, unless appropriate 
bandwidth has been allocated. 

4. 8. 3. 2.1 Required Bandwidth Calculations 

The bandwidth calculation tool for LCP is available on the Motorola Online website. 
https://businessonline.motorolasolutions.com 

The tool allows System Administrators to plug in to the LCP system configuration information to 
compute the IP bandwidth required for each site. Search for Linked Capacity Plus Bandwidth 
Calculator. 

4.8.4 Behaviors in Presence of Failures 



A Linked Capacity Plus system has no centralized controller and this makes it inherently tolerant to 
failures. The system automatically detects most types of failures, reconfigures itself, and continues 
to provide the services although with decreased capacity. This section provides the consequences 
of the failure of one or more entities of a Linked Capacity Plus system. 

4.8.4. 1 Failure of the Master 

If the Master is the only static IP address in the LCP system and it fails, if DHCP resets the 
dynamic IP addresses of the repeaters at one of the other sites before the static master is 
replaced, that site loses connectivity with the rest of the LCP sites. When the Master repeater is 
replaced, the site which had IP addresses reset can update the Master’s routing table and regain 
connectivity with the other sites. 

The consequences of a failure of the Master are limited. The system continues to function with 
exception that it is not possible to add a new site or repeater into the system. If a repeater powers 
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on while the Master is in failed state, then the repeater is not be able to join the system. Upon 
failure of the Master, it is possible to switch to a redundant repeater to act as the Master. The static 
IPv4 address and the UDP port number of the redundant repeater should be identical as that of the 
failed Master. Otherwise all repeaters are require to be reconfigured with the IPv4 address and the 
UDP port number of the new Master. 

4. 8.4. 2 Failure of a Site 

In absence of the periodic “Keep Alive” messages between a site and the Master, the Master 
concludes that either the IP Site Connect device or the network in-between has failed. The Master 
informs all the other sites about the absence of the failed site. The system continues to provide 
services with the available sites. During a network failure, it is possible that a Linked Capacity Plus 
system becomes multiple systems, whereby each system has a subset of the original set of sites. 
All new systems continue to provide the services that are possible with their subset of sites. Note 
that there is only one system that has the Master. When the backend network recovers, the 
multiple systems automatically become one system again. When a system has only one site, then 
the system behaves like a Capacity Plus system. 

4. 8.4. 3 Failure of a Repeater 

A repeater broadcasts “Keep Alive” messages periodically over the LAN. This allows a repeater to 
detect the failure of another repeater at its site. A failed repeater is not selected as a Rest Channel 
repeater. If a Rest Channel repeater fails, a new Rest Channel is then selected by the system. 

To help a radio detect the failure of a Rest Channel repeater, an inactive Rest Channel repeater 
periodically broadcasts a beacon over the Rest Channel. If a radio misses the beacon(s), then it 
knows that either the repeater has failed, or it is not within the coverage area of the repeater. 
Hence, the radio starts searching for a new Rest Channel. 

4. 8.4.4 Failure of the LAN Switch 

When the switch fails, a repeater cannot connect to other repeaters at its site. Each repeater then 
starts working as a two-channel trunking system. At the time of the switch failure, all radios may be 
on the Rest Channel or busy on other channels. In the first instance, the call capacity is severely 
impacted while in the second, radios on different channels are unable to communicate. 

4. 8.4. 5 Failure of the Backend Network or Router 

The failure of a router disconnects the site from the rest of the system. The failure of the backend 
network may disconnect one or more sites. When a site gets disconnected, it reconfigures itself 
and starts operating as a single site trunked system, that is like a Capacity Plus system. 

Intermittent failures of the backend network causes packet loss or excessive delay. Such failures 
adversely affect wide area talkgroup calls. A wide area call may fail to start at all the associated 
sites. LCP has built-in mechanisms to recover from such failures in a few seconds. 
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4. 8.4. 6 Failure of a Revert Repeater 

To overcome the failure of a revert channel repeater, a radio makes multiple attempts to transmit a 
data message on different channels. If a Trunked Control Station fails, a set of radios will not 
receive data messages from the Application Server. 

4.8.5 Automatic Reconfiguration 

A Linked Capacity Plus system automatically discovers the presence of a new entity such as a 
repeater, a site, or a Host PC. This new entity is configured with the IPv4/UDP address of the 
Master. Upon power-on, the new entity informs its IPv4/UDP address to the Master and the Master 
informs all the other entities about the presence of a new entity. Hence, this allows adding a 
repeater, site, or Host PC to a live Linked Capacity Plus system. This simplifies the installation/ 
addition of an LCP entity as there is no need to take the system down and configure other entities 
with the IPv4/UDP address of the new entity. 

A radio requires lists of all trunked and revert channels. This makes it necessary to reprogram all 
the radios when a physical channel (repeater) is added to the system. If a system is to be 
expanded in the future, and if these frequencies are known, then it is recommended to keep all 
future frequencies in the trunked list. Keeping additional trunked frequencies in the radio 
marginally slows down the radio operations when the radio is powered on, or when the radio 
comes out of fade. But this prevents the need to reconfigure all the radios when new repeaters are 
added. 

If a repeater needs to be removed from service for an upgrade or for repair, there is no need to 
reconfigure the radios. The MOTOTRBO Linked Capacity Plus system can still operate. 
Additionally, there is no need to power down the entire MOTOTRBO system while removing or 
adding a repeater in the system. 

4.8.6 Security Considerations 

MOTOTRBO offers two types of privacy mechanisms over-the-air - Basic Privacy and Enhanced 
Privacy. In Linked Capacity Plus and IP Site Connect configurations, a repeater does not decrypt 
the encrypted packets. It simply passes the packets as received over-the-air to other repeaters. 
Since the two privacy mechanisms are not compatible, all the radios and repeaters in a system 
should support the same privacy mechanism. 

NOTE: The privacy mechanisms protect only the voice or data payloads. They do not protect the 
voice or data headers, nor control messages, nor system messages (between repeaters). 

Similar to IP Site Connect, a Linked Capacity Plus system optionally offers authentication of all the 
packets sent between sites and host PCs. Packet authentication prevents an attacker from using 
an impersonator as a Linked Capacity Plus entity. This feature, if selected by a customer, requires 
manual configuration of the same key to all the entities. 

The above authentication mechanism does not provide protection against the replay attacks. For a 
more secure authentication, a Linked Capacity Plus configuration should use secure VPN routers 
to connect with the backend network. Secure VPN routers can optionally provide confidentiality of 
all the messages. However, a disadvantage of using these routers is that, the system requires 
more inbound and outbound bandwidth from the ISP. The use of these routers makes the 
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authentication mechanism of IP Site Connect redundant and should be disabled to save some 
bandwidth over the backend network. 

4.8.7 Migration 

The hardware of radios are fully compatible with the Linked Capacity Plus configuration. Only 
repeaters with 32 MB of internal memory (e.g. XPR 8380/XPR 8400 or MTR3000) can support the 
LCP configuration. 

While migrating multiple IP Site Connect or Capacity Plus systems into a Linked Capacity Plus 
system, it is important to ensure that the IDs of radios, radio IDs of the repeaters, and also the IDs 
of wide area talkgroups are unique. 

In LCP, both the Trunked Repeaters and the Data Revert repeaters have channel IDs. The range 
of the channel ID of a Data Revert repeater is 33 to 253. 

In Capacity Plus and IP Site Connect systems, each personality of a radio has a Rx Talkgroup List. 
In LCP, each site of a radio has a Rx Talkgroup List. 
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4.8.7. 1 Migrating from IP Site Connect 

To migrate from one or more IP Site Connect system(s), the following tasks are required: 

• Update the software of repeaters. 

• Update the software of radios. 

• Reconfigure both repeaters and radios. The reconfiguration should consider the 
following: 

• The range of the Layer 2 ID of radios in Linked Capacity Plus is 1 ..65535 
compared to 1.. 1677641 5 in IP Site Connect. 

• The range of the Layer 2 ID of talkgroups in Linked Capacity Plus is 1..254 
compared to 1.. 1677641 5 in IP Site Connect. 

In IP Site Connect, a call over a wide area channel is transmitted over-the-air at all the sites. A call 
over a local channel is transmitted over-the-air at the source site only. LCP does not have a local 
channel; allowing a customer to define a talkgroup as either local or wide-area in the Master 
repeater. For a wide-area talkgroup, enumerating the sites where the wide-area talkgroup call will 
be transmitted is allowed. Restricting the scope of a talkgroup to either local or to some sites 
improves the channel capacity of the system. Additionally, the ID of a local talkgroup can be 
reused at other sites and thus effectively increases the total number of talkgroup IDs. Unlike local 
channels, the local talkgroups do not require a radio user to change personality before PTT. 

4. 8. 7. 2 Migration from Capacity Plus 

To migrate from one or more Capacity Plus system(s), the following tasks are required: 

• Update the software of repeaters. 

• If the existing radios are going to operate at one site only, then it is not essential to 
update the software of radios. A Capacity Plus radio continues to operate in a Linked 
Capacity Plus system, within one site, with the following restrictions: 

• A call from a Capacity Plus radio at a site is not received by Capacity Plus or 
LCP radios at other sites. This implies that all the calls from Capacity Plus 
radios are local. 

• A Capacity Plus radio can receive a wide-area call only, but can not transmit. 

• A call from a Linked Capacity Plus radio is received by the Capacity Plus 
radios at the same site. 

• All the talkgroups used by Capacity Plus radios should be defined as local 
talkgroups in a Linked Capacity Plus system. 

• In Capacity Plus, the Lost Detection Beacon Interval in the radio is higher than 
the repeater’s. In LCP, the Lost Detection Beacon Interval must be the same in 
both radios and repeaters. 

4.8.8 Upgrading from Linked Capacity Plus 

Repeaters running on software version R02.20.12 or later are not interoperable with repeaters 
running on software version prior to R02.20.12. Hence, if there is a repeater with software version 
R02.20.12 or later present in a LCP system, all the other repeaters will have to be upgraded to 
R02.20.12 or later altogether. 
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When upgrading a Linked Capacity Plus system, upgrade the Master first, followed by all other 
repeaters at the Master's site. Continue to upgrade all the repeaters at a non Master site, ensuring 
completion of all repeaters at the site, before moving on to another peer site. During the upgrade, 
the LCP system acts as two mutually exclusive systems, but calls are still supported within, just not 
across the two systems. Therefore wide area calls may not reach all intended sites during the 
migration. All radios should remain tracking the legacy system until the last legacy repeater is 
switched off and upgraded at its site, radios will then find the new system and operate as normal. 
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4.9 Digital Voting 

The MOTOTRBO digital voting is a proprietary feature introduced in R02.30.00 to resolve the 
imbalance inbound-outbound issue. 

This section specifically documents the major control and monitor via CPS/RDAC for digital voting. 
Other control/monitor details can be found in corresponding CPS/RDAC manuals. 

The devices affected by this feature are the repeaters, satellite receivers and radios. For repeaters 
and satellite receivers, there are specific voting related software upgrades and configuration 
changes in firmware R02.30.02. However, for radios, there is none. Any radios running on 
software version R01.12.02 for MOTOTRBO, R02.30.01 and above for MOTOTRBO 2.0 or later 
are voting enabled out of factory. For older radios, they need to be upgraded to R02.30.01 or later. 

Unless specified otherwise, the control/monitor described in this section applies to all system 
configurations - Conventional Single Site, IPSO, Capacity Plus and Linked Capacity Plus. 

4.9.1 Configuring a Repeater to be a Receiver 

The satellite receiver is not a new hardware device. It reuses the MTR3000 repeater, 32 MB XPR 
series repeater, and the MTR3000 Receiver only box. The CPS needs to be configured for these 
devices to be used as satellite receivers. 

In a Capacity Plus or LCP system, the Rest Channel/Site IP address of a receiver is not used by 
the system, therefore it is not necessary to be the same Rest Channel/Site IP address in its voting 
repeater. Keep it simple by setting the address as 0.0. 0.0, or a proper LAN address that the 
receiver is in. 

If Enhanced GPS is enabled in the system, the receiver must not be configured as a scheduler. 
This means the periodic window reservation field in the “Enhanced GPS” section of the CPS must 
be set to “None” for both slots. 

4.9.2 Enable/Disable Digital Voting 

Repeaters: Voting can be enabled/disabled via CPS. When voting is disabled on a repeater, the 
repeater still performs as a regular repeater. However, the transmission of any call from its satellite 
receivers will not be accepted. 

Satellite Receivers: When the device is configured as a satellite receiver, the voting capability is 
programmed by default. If a particular satellite receiver needs to be taken down, the user can 
disconnect the satellite receiver from the system, power it down or use RDAC to disable it by using 
the “repeater disable” option. 

4.9.3 Digital Voting Status 

Digital voting status is monitored via RDAC. 

• Repeater Voting Enabled/Disabled - This status displays whether the voting feature on a 
repeater is enabled or disabled. 
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• Force Vote - This status indicates when the receiver is force voted. 

• Voting Status for Satellite Receivers - When voting is disabled on the repeater, RDAC 
does not display any voting status for its satellite receivers even if there are satellite receivers 
physically connected to the repeater. When voting is enabled on the repeater, RDAC then displays 
each satellite receiver’s voting status. The repeater pushes this information to the RDAC, and the 
update frequency is defined by the “Voting Status Update Rate” that is configured via the RDAC. 
The following voting statuses are possible: 

• N/A: This is the default value. Before RDAC obtains any information, this value 
is displayed. 

• Disabled: The receiver is voting disabled. 

• Not Synced: The receiver is voting enabled but has not synchronised with the 
repeater. The satellite will not operate in this state. This could happen during 
power up, or in a congested IP connection between the receiver and the 
repeater. 

• Synced: The receiver is voting enabled. It has synchronised with the repeater, 
but not receiving valid OTA transmission. 

• Receiving: The receiver is voting enabled, and is currently receiving valid 
transmission, but is not the voted winner. While in this condition, RDAC also 
displays the signal quality estimation (SQE). The SQE result is based on the 
voting parameters, and is categorized as “Excellent”, “Good”, “Fair”, “Poor”, 
and “Bad/Rejected”. 

• Voted: The receiver is voting enabled, currently receiving valid transmission, 
and is the voted winner. While in this condition, RDAC also displays the SQE 
based on the available voting parameters. 

• Voting Status for Internal Receivers (of the Repeater) - The voting repeater has a built- 
in receiver, and is defined as the “internal receiver”. When voting is disabled, RDAC does not 
display its internal receiver’s voting status. When voting is enabled, RDAC displays its internal 
receiver’s voting status. The repeater pushes this information to the RDAC, and the update 
frequency is defined by the “Voting Status Update Rate” that is configured via RDAC. The following 
voting statuses are possible: 

• N/A: This is the default value. Before RDAC obtains any information, this value 
is displayed. 

• Not receiving: The receiver is not receiving any valid OTA transmission. 

• Receiving: It is currently receiving valid transmission, but is not the voted 
winner. While in this condition, RDAC also displays the SQE based on the 
available voting parameters. 

• Voted: It is currently receiving valid transmission, and is the voted winner. 
While in this condition, RDAC also displays the SQE based on the available 
voting parameters. 

• Receiver Alarm/Failures - The satellite receiver reuses repeater hardware like the alarms 
and failure reports. All existing repeater alarms/failure reports, except for transmit only ones, are 
still available for the satellite receivers. 



NOTE: The satellite receiver does not transmit over the air. 
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4.9.4 Digital Voting Controls/Configurations 

For repeaters, there is no additional voting related configuration, except enabling/disabling the 
voting feature. 

For satellite receivers, the following controls/configurations are available: 

• Connected Voting Repeater/Radio ID - A satellite receiver must be connected to a voting 
repeater via IP LAN or WAN. In order for the satellite receiver to operate correctly, it needs to know 
which voting repeater it is associated to. This can be configured by the CPS. 

• Force Vote/Cancel - There are situations when a particular satellite receiver or the repeater 
needs to be always selected as the voted winner for a period of time. For example, a critical 
activity near a particular receiver occurs, thus calls from that receiver need to have higher priority. 
This can be achieved via force vote from the RDAC. When the RDAC user force votes a particular 
satellite receiver/repeater, the transmission received from that particular receiver/repeater will 
always be selected as the voted winner, and repeated until force vote is cancelled, or until the 
force voted receiver is disconnected from the system. 

• Voting Status Update Rate - This controls how often the voting status of the repeater and 
its satellite receivers should be updated in RDAC. There are 3 control options: 

• None: The status is not pushed to the RDAC. This option reduces the traffic 
between the repeaters and the RDAC, thus alleviates network traffic in the 
system. 

• Normal: The status is continuously pushed to the RDAC at an interval of every 
three (3) seconds. This is the default value. 

• Diagnosis: The status is continuously pushed to the RDAC at an interval of 
every one (1) second. This should be used only for diagnosis purpose, 
because frequent status updates increase the IP traffic, and add heavy 
workload into the system dramatically. 

• Voting Log Turn On/Off - Voting log may be turned on/off for a specific voting repeater via 
RDAC. The update rate of the logged information is decided by the “Voting Status Update Rate”. 
Once turned on, RDAC logs the following voting related information for the repeater, and each of 
its satellite receivers: 

• Repeater voting enable/disable status with PC time stamp 

• Voting status of its receivers with PC time stamp 

• Estimated network asymmetry and number of bursts arrived late with PC time 
stamp 

• DV Stability Factor - This is configured via CPS. It utilizes the crystal oscillator in the 
device, and the accuracy of the crystal oscillator is decided by lots of factors such as receiver 
device age and environmental temperature. To achieve optimum system performance, 0.5 is the 
best default value to handle all common situations and should not be changed. However, if 
constant timeslot swap due to extreme non-network environmental conditions is observed 
between the receiver and its voting repeater, the value can be increased to solve this timeslot 
problem. 

• Existing RDAC Controls - The satellite receiver reuses repeater hardware, like for 
example, repeater disable. All existing repeater controls, except for transmit only ones, are still 
available for the satellite receivers. 
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4.10 Digital Telephone Patch (DTP) 

The MOTOTRBO Digital Telephone Patch is a Motorola proprietary feature introduced in software 
version R01 .08.00. 

This section specifically documents the major configuration planning and error-prone configuration 
details for phone patch calls. Other configuration details can be found in corresponding CPS 
manuals. 

Unless specified otherwise, the configuration described in this section applies to all system 
configurations - Conventional Single Site, IPSC, Capacity Plus and Linked Capacity Plus. 

4.10.1 Enable/Disable Phone Gateway Repeater for Phone Calls 

When a repeater is connected to an APP box and used for phone calls, it is called a phone 
gateway repeater. Only phone gateway repeaters are capable of hosting phone calls. The 
repeater’s radio ID is used as the target ID representing the landline phone user in an individual 
phone call. Hence, the ID must be different from any subscriber’s radio ID or other repeaters’ radio 
ID in the system. 

The phone call duration is typically longer than a regular 2-way radio voice call. If the phone 
gateway repeater’s TOT is set to be too short, it is possible that the timer expires and causes a 
brief interruption during a phone call. In order to eliminate such interruption and to provide a better 
end-user experience, it is recommended to set the timer to 300 seconds or longer. 

Conventional Single Site or IP Site Connect 

The APP box can be configured to support none, one or both of the channels of the phone 
gateway repeater for phone calls. If the APP box needs to support phone calls on only one of the 
channels, this channel has to be enabled as the phone gateway, while the other channel disabled 
on this repeater. 

Example: In IPSC, the APP box may be configured to support one of the WACs, while another 
APP box at a different site may be configured to support the other WAC. 

If the APP box needs to be used to support phone calls on both channels, both channels need to 
be phone gateway enabled. If the APP box cannot be used to support phone calls on either 
channels (although physically connected to the repeater), both channels need to be phone 
gateway disabled. 

IP Site Connect 



If there is a legacy repeater (prior to R01 .08.00) on a WAC, any phone capable repeater needs to 
be phone gateway disabled for that particular WAC, because phone calls are not supported in 
legacy repeaters. 

Capacity Plus and Linked Capacity Plus 

Because the channels are trunked, the CPS configuration to support phone calls is at the repeater 
level instead of the channel level. The APP box can only be configured to support either both or 
none of the channels of the phone gateway repeater for phone calls. The radio ID value of the 
phone gateway repeater must not exceed 65535 (OxFFFF). 
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In Conventional Single Site, IPSC LACs and Capacity Plus configurations, once a repeater 
channel is phone gateway disabled, no phone calls can take place on this channel. However, in 
IPSC WACs, there may still be phone calls on the channel hosted by an APP box from another 
site. In Linked Capacity Plus, phone calls can be received from a remote site. However, a radio 
can initiate the phone call only from its current site. 

4.10.2 Enable/Disable a Radio from Initiating/Receiving Phone Calls 

A radio’s capability of initiating/receiving phone calls can be enabled/disabled on a per digital 
personality basis. This is especially useful if there is a need to prevent a radio from participating in 
phone calls on some particular channels. 

This configuration capability is done by connecting or disconnecting a phone system to the 
channel on the selected personality. 

• Conventional Single Site or IPSC LACs - If a phone system is connected to the selected 
Home channel, the radio can initiate/receive phone calls, Otherwise, phone capability is disabled. 

• IPSC WAC - If a phone system is connected to the selected Home channel (not the channel 
from the roaming list), the radio can initiate/receive phone calls from any site on the WAC. 
Otherwise, phone capability is disabled. 

• Capacity Plus - If a phone system is connected to any channel from the channel list on the 
selected digital personality, the radio can initiate/receive phone calls on that channel. Otherwise, 
phone capability is disabled. 

• Linked Capacity Plus - If a phone system is connected to any channel of the current site, 
the radio can initiate phone calls. Otherwise, phone capability is disabled. However, a radio can 
receive a phone call if a site in the system has a phone system. 

4.10.3 Enable/Disable Pre-Configured Target ID 

A pre-configured target ID may be used for each phone gateway repeater, and this capability can 
be enabled or disabled via CPS. Once enabled, one default target ID can be pre-configured in the 
phone gateway repeater. Different phone gateway repeaters may use different pre-configured 

target IDs. 
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4.10.4 Phone Channel Configuration 

4.10.4.1 One APP Box per Repeater via 4-wire Interface 

In all system configurations, the physical connection for DTP is the 4-wire interface between the 
repeater and the APP box, which is identical to the APP configuration. The physical connection is 
through the repeater’s GPIO connector, with the following pins: 

• TX Audio - Input impedance (AC) of 560 ohms, Single-ended 

• RX Audio - Single-ended 

• PTT- 5 v level GPIO 

• COR-5v level GPIO 

• Ground 

4.10.4.2 Single Site 

When a repeater is connected to an APP box in a Single Site configuration, both channels of the 
repeater can be used as phone channels. The phone calls on either of these two phone channels 
use the same APP box that is connected to the repeater. 

Since both channels are phone channels, the radio or phone user needs to specify which channel 
to use when initiating the call. The radio user can manually switch to the phone channel where the 
call shall start on. The phone user can specify which channel to use when prompted for Target ID 
by the repeater. 
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4.10.4.3 IP Site Connect 

Each logical channel (either WAC or LAC) can only use at most, one APP box, and the APP box 
can be connected to any repeater that is part of the logical channel. One APP box may support up 
to two logical channels if these two channels are on the same repeater that the APP box is 
connected to. However, only one logical channel can be supported at a time. 

Similar to the call initiation in a Single Site configuration, the radio or phone user needs to specify 
which channel to use when initiating the call. The radio user can manually switch to the phone 
channel where the call shall start on. The phone user can specify which channel to use when 
prompted for Target ID by the repeater. 

4.10.4.4 Capacity Plus 

When a repeater is connected to an APP box in a Capacity Plus configuration, both channels of 
the repeater can be used as phone channels. The phone calls on either of these two phone 
channels use the same APP box that is connected to the repeater. In order to support phone calls, 
all voice repeaters in the system need to be upgraded to R01 .08.00 or later. 

The radio user does not select which phone channel to use when initiating a phone call because 
Capacity Plus is a trunked system. The system instead selects an available phone channel 
automatically for the call. When the phone user initiates the call, he/she calls the phone number of 
the APP box or PBX, but does not specify which channel of the repeater to use. 

4.10.4.5 Linked Capacity Plus 

When a repeater is connected to an APP box in a Linked Capacity Plus configuration, both 
channels of the repeater can be used as phone channels. The phone calls on either of these two 
phone channels use the same APP box that is connected to the repeater. In order to support 
phone calls, all voice repeaters in the system need to be upgraded to R02.01 .00 or later. 

The radio user does not select which phone channel to use when initiating a phone call because 
Linked Capacity Plus is a trunked system. The system automatically selects an available phone 
channel of the local site for the call. When initiating a phone call, the phone user calls the phone 
number of the APP box or PBX, but does not specify which channel of the repeater to use. 

The radio user can initiate an individual phone call or a local talkgroup phone call or a wide-area 
talkgroup phone call based upon the selected personality. When roaming from one site to another, 
the radio user can only initiate the phone call on the roamed site. Initiating the phone call from the 
local site to the phone capable repeater on the remote site is not supported in a Linked Capacity 
Plus system. 

4.10.5 APP Box Configuration 

The DTP feature is designed to work with most of the COTS APP boxes. The APP box installed 
needs to have the type approval for the region that the system is deployed. One end of the APP 
box is connected to the PSTN or an extension of a PBX box, while the other end is connected to a 
MOTOTRBO repeater via the 4-wire interface. To work with the MOTOTRBO system, the APP box 
needs to be configured to use half-duplex mode. Depending on customer needs and the type of 
APP boxes, the following services can be optionally configured in the APP box: 
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• Access and De-access Codes (10 characters maximum) - 

• The access code is made up of an access command and a multi-digit access prefix. 
Nomenclature may vary based on the types of APP boxes. The access command is 
typically the asterisk (*) sign, but is programmable in most phone patches. The 
command is used to wake up the phone patch from the radio system, and is always 
required for most of the APP boxes. The multi-digit access prefix is used to limit radio 
user access and is optional. The prefix is usually up to four digits long. Some phone 
patches allow each prefix to be configurable to allow or block calls starting with 0, 1, 9, 
and so on. This essentially allows a group of radio users to have access to local dialing. 

• The de-access code is made up of a normal release command and a multi-digit release 
code. Nomenclature may vary based on the types of APP boxes. The normal release 
command is typically the hash (#) sign, but is programmable in most phone patches. 
The command is used to hang-up the phone patch from the radio system, and is always 
required for most of the APP boxes. The multi-digit release code is optional, and only 
used to limit who can hang up a phone call when required. 

• Multi-digit access prefixes and multi-digit release codes can be linked within most phone 
patches. This allows phone calls that are started with a particular access code to only be 
hung up on, with the linked de-access code. This is especially useful for Group Phone 
Calls since any user can attempt to hang up a phone call. Utilization of a particular 
access code for group calls that is linked to a de-access code most Radio Users don’t 
have will limit who can hang up on a Group Phone Call. 

• Phone Usage TOT - This defines the maximum duration of a phone call. If the phone call 
lasts longer than this timer, the APP box ends the call automatically. It is recommended to 
configure this timer appropriately according to the customer’s phone usage. 

• Mobile inactive timer - If there is no radio activity for a period longer than the mobile 
inactive timer, the APP box ends the phone call automatically. It is recommended to configure this 
timer appropriately according to the customer’s phone usage. 

• Go ahead tone - The phone user hears this tone when the radio user de-keys. If this tone is 
provided by the APP box, it is recommended to enable this option to improve the phone user’s 
experience during a phone patch call. 

• Busy Tone Disconnect - When this APP option is enabled, the APP box ends the phone 
call once a PSTN busy tone is detected. It is recommended to turn on this option if it is provided in 
the APP box. 

For further information on how to connect the APP box to the repeater, and APP box tuning details, 
please refer to the respective repeater service manuals. 

4.10.6 Phone System Configuration 

There are many phone related configurations that defines how a radio/repeater communicates 
with the PSTN and support phone calls in the radio system. To make the configurations easier, a 
data structure called “phone system” is introduced to group and encapsulate these configurations. 
Because radios and repeaters act in different roles in a phone call, the configurations 
encapsulated in the phone system are different for radios and repeaters. The phone system in a 
repeater includes configurations such as de-access code, busy TOT and so on. The phone 
system in a radio includes configurations such as gateway ID, access code, and others. 
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4.10.6.1 Configuring a Radio in a Phone System 

For a radio, multiple phone systems can be created and configured via CPS. The phone system 
defines how the radio interacts with the PSTN via a particular APP box, hence a valid phone 
system must have a corresponding APP box in the system. However, a radio may interact with the 
PSTN via an APP box in different ways. Therefore it may have more than one phone system for a 
particular APP box. 

Example: If there is only one APP box in the system, but if a radio uses different access/de- 
access codes on different digital personalities, different phone systems can be created 
and each phone system will have different access/de-access codes. 

If a radio needs to initiate or receive phone calls on a selected digital personality, a phone system 
(or systems, in Capacity Plus and Linked Capacity Plus) must be linked to the channel (or 
channels, in Capacity Plus and Linked Capacity Plus) on per digital personality basis via CPS. The 
phone system linking varies according to different system configurations. 

• Conventional Single Site and IPSC LAC - The phone system is linked to the channel 
whereby the corresponding repeater is physically connected to the corresponding APP box. 

• Capacity Plus - Multiple phone systems may be available for a selected digital personality. 
A phone system is linked to the channel whereby the corresponding repeater is physically 
connected to the corresponding APP box. 

• IPSC WAC - If there is an APP box on this WAC, the corresponding phone system must be 
linked to the selected Home channel even if the phone system is physically connected to a 
repeater at the remote site. 

• Linked Capacity Plus - Multiple phone systems per site may be available for a selected 
digital personality. A phone system is linked to a repeater at the site whereby the corresponding 
repeater is physically connected to the corresponding APP box. The destination talkgroup ID of a 
phone-to-radio call determines whether a phone call is a wide area or a local area phone call. Note 
that if the destination is an individual radio, then the phone call is initiated at all sites. A radio can 
initiate the phone call only on its current site. A wide-area talkgroup phone call is successful when 
all associated sites within the talkgroup have an idle channel to host the call. 

4.10.6.2 Configuring a Repeater in a Phone System 

For a repeater, there is one and only one repeater-wide phone system. The user is allowed to 
configure the phone system but not allowed to create additional ones. Additionally, only the phone 
system in a phone gateway repeater needs to be configured. 

4.10.7 Access/De-access Code Configuration 

Access and de-access codes are encapsulated in the phone system. Depending on the 
customers’ needs and the type of APP box installed in the system, access/de-access codes may 
be optionally required to initiate/end phone calls. Different sets of access/de-access codes can be 
used for initiating/ending different types of calls (e.g. long distance call, international call, etc). The 
codes are normally configured and supported in pairs in the APP box; if a particular access code is 
used to start the call, the corresponding paired de-access code must be used to end the call. 





348 



System Design Considerations 



Additionally, administrator access/de-access codes may be used. The administrator codes have 
the highest priority, and can be used whenever access/de-access code is required. For example, 
the administrator de-access code can be used to end a phone call, regardless which access code 
was used to initiate the call. 

A system may have more than one APP box installed, and these boxes may be used to simply 
expand the number of phone channels, or for different purposes. For example, one APP box may 
be used for international calls, while the other boxes to expand the number of channels. The 
access/de-access codes in these APP boxes may be configured similarly, or different depending 
on how phone privileges are assigned among the radios users. The configuration also depends on 
whether the codes are to be entered by the radio users, or configured in the radios. 

4.1 0.7.1 Repeater Configuration 

If a repeater is not used as a phone gateway repeater, there is no access/de-access code 
configuration for the repeater. 

However, if the repeater is used as a phone gateway repeater, a de-access code must be 
configured in the repeater. This is mandatory even if the multi-digit release code part of the de- 
access code is not required; the normal release command part of the de-access code must be 
provisioned. The repeater needs the de-access code to end the phone call when the phone call 
needs to be ended by the radio system automatically, especially during an Emergency Alarm 
interrupt. Since the repeater can only hold one de-access code, this code configured in the 
repeater must be able to end any phone call supported by the APP box that is connected to the 
repeater. If the APP box supports administrator access/de-access codes, multiple sets of codes 
can be used in the system, and the administrator de-access code needs to be programmed in the 
repeater. However, if the APP box does not support administrator access/de-access codes, only 
one de-access code can be used for this connected APP box and the same de-access code must 
be programmed in the repeater. 

NOTE: The APP box can still use different sets of access/de-access codes, but the de-access 
codes must be the same. 

Otherwise, the repeater may not be able to send the appropriate de-access code to end the call 
when an Emergency is detected during a phone call. 

Since a repeater only interacts with a connected APP box, the repeater configuration does not 
impact how the access/de-access codes are configured in other APP boxes in the system. 

4.10.7.2 Radio Configuration 

If access/de-access codes are not required for phone calls, there is no related access/de-access 
code configuration in the radio. 

However, if required, the system can be programmed to have the codes stored in the radio and 
sent out automatically, or via some simple user interaction like pushing a button. Alternatively, the 
system can be programmed for the radio user to enter and send out the access/de-access codes 
manually when needed. 

When the codes are configured in the radio via CPS, the radio uses the code programmed for the 
foreseen channel automatically, before initiating or ending a phone call on that particular channel. 
This process is transparent to the user. Hence, there is no restriction on the usage of multiple sets 
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of access/de-access codes for a particular APP box, or whether different APP boxes in the system 
can use different sets of access/de-access codes. 

When the access/de-access codes are not programmed in the radio, the code configuration in the 
APP box is different depending on the system configurations. 

4.10.7.2.1 Single Site or IPSC Systems 

When a phone call is started, the radio user needs to select which channel to make the phone call. 
Therefore, the radio user knows which channel and which APP box the phone call is occurring on, 
hence which access/de-access code to use. In these system configurations, multiple sets of 
access/de-access codes can be used and the codes may differ in different APP boxes in the 
system. 

4.10.7.2.2 Capacity Plus and Linked Capacity Plus Systems 

Because the phone channel is selected by the system automatically, the radio user does not know 
the channel information when entering the access/de-access code. Therefore, multiple sets of 
codes can be used in a Capacity Plus system, but they must be the same in all the APP boxes if 
the codes need to be entered manually by the radio user. 

4.10.8 Dual Tone Multi Frequency (DTMF) Configuration 

During a phone call, the phone numbers are generated and go through the system in the form of 
DTMF tones. These DTMF tones interact with components that are not part of the MOTOTRBO 
system. For example, APP, PBX, PSTN, and others. Hence, the generated DTMF tones must be 
compliant with the local DTMF generating/receiving standards in order for these components to 
receive and understand the DTMF tones generated from the MOTOTRBO system. The following 
DTMF parameters are configurable both in the radio and repeater via CPS: 

• DTMF Tone Duration 

• DTMF Inter-Tone Delay 

NOTE: DTMF Tone Level is a codeplug value, but not CPS configurable because it normally does 
not require change. DTMF Twist is not configurable and is always set to zero. 

4.10.9 Ringing Modes 

When a radio user calls a phone user, the phone keeps ringing until the phone user answers. Or, 
the radio user ends the call, or the call gets timed out by the PSTN. 

When a phone user calls a radio user, there is only one ringing mode. The radio keeps ringing until 
the radio user answers the call, or the call gets timed out by the repeater. 

When a phone user calls a radio group (talkgroup), there are two ringing modes. These modes are 
configurable in the repeater via CPS. The first method is where the radio keeps ringing until one of 
the targeted radio users answers the call by pushing PTT and talking back. Or, the call gets timed 
out by the repeater. The second ringing mode is to allow the phone user to talk immediately after 
the first ring. The second method allows phone users to talk first during a phone call. 
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4.10.10 Enable/Disable Manual Dial 



Manual dial allows a radio user to enter the phone number manually using the radio keypad. To 
prevent misuse of the phone services in the system, this manual dialing option can be enabled/ 
disabled via CPS on a radio wide basis. 

4.10.11 Connecting APP Boxes to the Repeater in Capacity Plus and 
Linked Capacity Plus 

In Capacity Plus, only the voice channel repeaters can be connected to the APP boxes to support 
phone calls. When connecting the APP boxes to the repeaters, it is highly recommended to 
connect the APP boxes to the repeaters with lowest possible rest channel priorities first. This 
balances the traffic on the channels. In such a configuration, the non-phone calls are likely to 
occur on the repeaters with higher rest channel priorities, while phone calls occur on the repeaters 
with the lowest rest channel priorities. 

4.10.12 PBX Routing Configuration in Capacity Plus 

PBX can be used with the DTP systems. However, if a repeater is disabled, the repeater does not 
inform the PBX that it is disabled. In this scenario, the administrator needs to take action to ensure 
that the PBX does not route the incoming call from the PSTN to the disabled repeater. Otherwise, 
the phone user will not be able to connect to the radio users. 

PBX may have different priorities when PBX assigns the extension lines for incoming calls from 
the PSTN. In Capacity Plus, the traffic on a channel with higher rest channel priority is normally 
heavier than the channel with lower rest channel priority. Therefore, if the system has two or more 
APP boxes, it is recommended to have the PBX route the incoming phone call first to the APP 
boxes that are connected to repeaters with lower rest channel priorities. As a result, this balances 
the voice traffic on all channels. 
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4.11 Transmit Interrupt System Design Considerations 

Transmit Interrupt is a very powerful feature; it is capable of remotely dekeying a radio that is 
transmitting interruptible voice. Hence, limiting access to these features only to responsible and 
well-trained radio users is important. 

If a radio operates on a channel that supports Direct Mode Transmit Interrupt features, then the 
“TX Interrupt Direct Mode Compatibility” CPS field should be enabled. This is necessary to 
minimize potential collisions on the channel during a Direct Mode interruptible voice transmission. 
This field must be enabled in the CPS; both for Direct Mode channels where interruptible voice 
transmissions may be present, and Repeater Mode channels where interruptible voice 
transmissions may be made by some radios in Talkaround Mode. However, it is not necessary to 
enable this field for Repeater Mode channels where Talkaround mode is not supported by any 
radio. 

4.11.1 Interruptible Radios 

The first consideration associated to the Transmit Interrupt features is determining which radios’ 
voice transmissions should be interruptible. For consistent behavior, the recommendation is that 
all radios operating on a channel should use interruptible voice transmission. However, it is 
desirable in some applications, to provide a small number of radios (e.g., normally supervisor 
radios) that are not interruptible. 

This sets up a system where supervisors have the ability to interrupt non-supervisor’s interruptible 
voice transmissions, but non-supervisors cannot interrupt supervisor’s voice transmissions, 
because the supervisor radios do not transmit interruptible voice. When the system is configured 
as such, both the supervisor and non-supervisor radios may succeed at interrupting when a non- 
supervisor is transmitting interruptible voice, and fails at interrupting when a supervisor is 
transmitting uninterruptible voice. This situation may be perceived by some users as an 
inconsistent experience. If the system is set up in this manner, the users should be given training 
on the usage of Transmit Interrupt to better understand the difference in experience. 

4.11.2 Voice Interrupt 

During an interruptible voice transmission, a transmitting radio periodically checks its receive 
frequency and determines whether another radio is requesting an interrupt. Therefore, interrupting 
radios must transmit their interrupt signaling when the transmitting radio is checking its receive 
frequency. When only one radio within a group is capable of Voice Interrupt (e.g., a supervisor 
radio), then that radio uses one of the periodic signaling intervals to signal an interrupt request, if 
an interrupt is requested by the radio user. 

When two radios are capable of Voice Interrupt (e.g., two supervisor radios), it is possible that both 
radio users request a Voice Interrupt at nearly the same time (i.e., during the time between two 
periodic signaling intervals). If this happens, it is likely that the interrupt procedure fails for both 
radios, due to a signaling collision that occurs during the periodic signaling interval and neither of 
the radios succeed at obtaining a clear channel on which to transmit. 

Extending this discussion to beyond two radios (e.g., additional group members configured with 
Voice Interrupt capability), it becomes even more likely that more than one radio user requests a 
Voice Interrupt at nearly the same time, resulting in a signaling collision and a failed interrupt 
procedure. The likelihood of more than one radio user requesting a Voice Interrupt at nearly the 
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same time is difficult to predict or estimate, because this depends heavily on the usage 
characteristic profile of a particular system, operating procedures implemented by the system 
administrators, and the training provided to the radio users. 

Example: Some systems may provide every radio user with Voice Interrupt capability and 
experience no signaling collisions resulting in Voice Interrupt failures. On the other 
hand, other systems similarly provisioned would experience many Voice Interrupt 
failures. Yet other systems may provide only a few radios users with Voice Interrupt 
capability, but experience high rates of collisions and Voice Interrupt failures. 

NOTE: Performance varies by system. 

To maintain radio user experience at an acceptable level, the following suggestions can be 
provided when training radio users on the desired usage of Voice Interrupt on a particular system: 

• Provide the Voice Interrupt capability to only radio users that need to have such 
capability. Minimize the number of users within a group that have Voice Interrupt 
capability. 

• Use good radio protocol. Keep transmissions as short as possible and wait until the 
transmitting radio user has stopped talking and dekeyed (e.g., wait to receive a Channel 
Free Tone) before beginning a new transmission. 

• Be aware of situations near the end of a transmission when the radio user has stopped 
speaking, but has yet to dekey the radio. 

• Create guidelines for acceptable use of the Voice Interrupt feature; define when it is 
acceptable to interrupt another radio user’s transmission, (e.g., Voice Interrupt is only 
used when late-breaking information has become available that is critical to disseminate 
immediately.) 

• Be aware of situations where the transmitting radio user says something that may elicit 
an immediate reaction from the listening audience, and either curb the desire to respond 
immediately or allow a designated radio user (e.g., a supervisor or dispatcher) to use 
Voice Interrupt to respond, to maintain order on the channel. Alternatively, train users to 
wait a short period of time before responding to the transmitting radio users. 

4.11.3 Emergency Voice Interrupt 

The Emergency Voice Interrupt feature is used only during emergency conditions, which are 
presumed to occur relatively infrequently and affect radio users individually. Based on these 
assumptions, it is appropriate to enable Emergency Voice Interrupt in every radio if so desired. If 
emergency conditions are expected to occur frequently or affect large groups of users (i.e., many 
radio users initiate emergency or are in an emergency condition simultaneously), then Emergency 
Voice Interrupt users may experience the collisions described in “Voice Interrupt” and Emergency 
Voice Interrupt may not perform to the end users’ expectations. 

In a Capacity Plus configuration, this feature is used to stop a voice transmission during an 
emergency based on the following two conditions: 

• If all channels are busy, a radio starts an Emergency Call after interrupting an ongoing 
interruptible call on the busy Rest Channel. 

• If an Emergency Call is active for the same talkgroup on channel ‘c’, a radio starts the 
Emergency Call on channel ‘c’ after interrupting the ongoing interruptible call. 
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4.11.4 Data Over Voice Interrupt 

Data Over Voice Interrupt is not used by any data applications native to the radio (e.g., Text 
Message, Location, Telemetry). This feature is only available to third-party data applications on the 
option board or attached PC. 

It is suggested that third-party data applications only invoke the Data Over Voice Interrupt feature 
for the most critical of data; data that is more important than the interruptible voice transmission on 
the radio channel. It is also suggested that the third-party data application be designed to ensure 
that system events common to multiple radios do not result in Data Over Voice Interrupt 
transmissions being initiated simultaneously. These guidelines are necessary to minimize the 
probability of Data Over Voice Interrupt signaling requests from colliding with one another. As 
discussed in the Voice Interrupt section above, it is likely that the interrupt procedure fails, and 
none of the radios succeed at obtaining a clear channel on which to transmit, when the signaling 
collides. 

In a Capacity Plus configuration, a data message invokes this feature, dependent on the following 
conditions: 

• If the radio is transmitting a voice call (either on a traffic channel or on a busy Rest 
Channel), the radio continues with the voice transmission. 

• If the radio is on a busy Rest Channel (either listening or idling) and the data message 
must be transmitted on a Trunked Channel, this feature is used to stop the ongoing 
voice transmission. 

• If the radio is listening to a voice call on a traffic channel (not on a busy Rest Channel) 
and the data message must be transmitted on a revert channel, the radio moves to a 
revert channel to invoke this feature. 

• If the radio is listening to a voice call on a traffic channel (not on a busy Rest Channel) 
and the data message must be transmitted on a Trunked Channel, the radio moves to 
the Rest Channel to invoke this feature. However, if the Rest Channel is busy, this 
feature is then used to stop the ongoing voice transmission. Note that the receiving 
radio may be busy on another channel and there is no guarantee that the data message 
will be received. 

In summary, a radio does not attempt to interrupt if: 

• The radio is transmitting. 

• The data message is for a revert channel. 

• The Rest Channel is idle. 
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4.11.5 Remote Voice Dekey 

The Remote Voice Dekey feature is capable of dekeying interruptible voice transmissions that the 
radio is either partied to, or not partied to. Alternatively, the radio user has the ability to remotely 
shut down a transmission that the user is not able to first monitor. Because of this, it is suggested 
that the Remote Voice Dekey feature be provided only to well-trained supervisors or radio 
technicians. 

Operational procedures regarding appropriate use of this feature should be established to ensure 
that the user is not remotely dekeying critical voice transmissions. It is presumed that Remote 
Voice Dekey is not used frequently, therefore the collisions described in the Voice Interrupt section 
is not a major concern. 

In Capacity Plus/LCP mode, a radio can always dekey interruptible voice transmissions that it is 
partied to; Also, it can dekey the interruptible voice transmission on a busy rest channel that it is 
not partied to if the radio is not participating in a call on other channel. 
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4.12 Restricted Access to System (RAS) Design 
Considerations 

Historically, repeaters in the system were not well protected against unauthorized radio access. If 
an unauthorized radio user (outside of the system) wanted to utilize the repeaters for voice/data/ 
CSBK communications, the user could have illegally programmed their radios with the system’s 
channel information and gained access. It was not difficult to get the system’s channel information 
-the unauthorized user could simply analyze OTA bursts, or just read the CPS configurations from 
any valid radio in the system. 

The RAS feature is designed to prohibit unauthorized radio users from accessing the repeaters in 
the system. When this feature is enabled, the unauthorized radio user is restricted from using the 
repeaters in the system to transmit to the targeted user or user group. 

This feature does not apply to Dual Capacity Direct Mode, Direct Mode or Talkaround Mode 
transmissions. 

The RAS feature applies only to Digital, Single Site, IP Site Connect, Capacity Plus and Linked 
Capacity Plus system configurations. The usage and user experience in these systems are similar. 
In order to enable this system wide feature, all the repeaters in the system need to have RAS 
capability. This feature is software upgradable for all MOTOTRBO 8 MB and 32 MB repeaters. 

This feature has no impact to the existing ADP interfaces except that the repeater notifies the 
relevant application when blocking of an unauthorized transmission has occurred. Further details 
are available in the ADP document. 

This feature includes two independent methods: RAS Key Authentication and Radio ID Range 
Check. These two methods apply to all voice, data and CSBK calls of repeater mode. When used 
together, the combination provides a robust and flexible way to protect the system from 
unauthorized access. 

4.12.1 RAS Key Authentication 

In this method, both the repeater and subscriber are configured with a secret RAS authentication 
key. The length of the key can be 6 to 24 characters long, and may include numbers 0-9, alphabet 
letters A-Z, a-z, special characters like hyphen, underscore, dollar and pound signs. Similar to the 
enhanced privacy keys, the RAS authentication key cannot be read out via CPS or cloned from 
one device to another device once configured and written into the radio or repeater. 

Therefore, an unauthorized user cannot see the key, nor clone more radios by simply obtaining a 
radio programmed with the valid key. Additionally, similar to the enhanced privacy keys, when 
configuring a RAS enabled radio, the user needs to remember and retype the key when writing 
back to the radio via CPS. 

A subscriber uses its configured authentication key to encode the OTA bursts and generate a RAS 
enabled transmission. Upon receiving the bursts, the repeater also uses its configured 
authentication key to decode the bursts. If the authentication keys in the subscriber and repeater 
are the same, the repeater is able to decode the bursts correctly and repeat the bursts. However, if 
the radio does not have a RAS authentication key or its key does not match the one that is 
configured in the repeater, the decoding process in the repeater fails and the transmission is 
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blocked at the repeater. Therefore, the call bursts from the unauthorized subscriber are not 
repeated and cannot reach the targeted user or user group. 

Each system only needs one RAS authentication key, all the repeaters in a system are provisioned 
with only one key. To simplify the key configuration in a multi-repeater systems, the key only needs 
to be configured in the master repeater. Subsequently, the key is propagated to all the other peer 
repeaters automatically. The repeater, and eventually the system may be configured in only one of 
the three RAS modes: 

• RAS Disabled: When the repeaters are configured in RAS disabled mode, the RAS key 
authentication method is not used. Hence the system supports calls from RAS disabled 
subscribers and legacy subscribers, including third party compatible subscribers, but not 
RAS enabled subscribers. 

• RAS Enabled: When the repeaters are configured in RAS enabled mode, only RAS 
enabled subscribers with valid keys are supported and can successfully make calls 
through the repeater. 

NOTE: The system must not be configured in RAS enabled mode until all the repeaters and 
subscribers have been upgraded to have RAS capability. Otherwise, the repeaters or 
subscribers that are not RAS capable will not be able to operate normally in the system. 

• RAS Migration: When the repeaters are configured in the RAS migration mode, the 
repeater accepts both DMR transmission and RAS enabled transmission in the repeater 
inbound. If the inbound is DMR transmission, the repeater repeats it out as is. If the 
inbound is RAS enabled transmission, the repeater converts it to DMR transmission and 
repeats it out. Therefore, in the RAS migration mode, the system supports all 
subscribers including RAS disabled, RAS enabled with the valid RAS key and legacy 
subscribers. The RAS migration mode is recommended when installing a new system, 
migrating a legacy system to RAS enabled mode, or in any cases where the system 
needs to support both legacy and RAS enabled subscribers. 

Example: When migrating a legacy system, the administrator may first provision the key to all the 
repeaters and let the system to operate in the RAS migration mode. Next, the 
administrator could use the CPS or OTAP to provision the key to all the subscribers in 
the system. Since the system operates in RAS migration mode, both the legacy 
subscribers and the RAS enabled subscribers with the valid key can operate in the 
system normally and make successful calls through the repeater. After all the 
subscribers are provisioned with the key, the administrator can change the system to 
operate in RAS enabled mode to prevent any unauthorized subscribers from accessing 
the system. Therefore, the RAS migration mode provides smooth system installation 
and migration without interrupting the services. 

However, a subscriber can be configured only in two RAS modes: 

• RAS Enabled, or 

• RAS Disabled. 

When the subscriber is RAS disabled, it is not able to transmit or receive RAS enabled 
transmission, hence operates only in a RAS disabled or RAS migration system. When the radio is 
RAS enabled, it always transmits the RAS enabled bursts, but receives both DMR bursts and RAS 
enabled bursts. Therefore, RAS enabled subscribers can operate in RAS migration or RAS 
enabled systems. 
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A radio may operate in different systems and these systems may have different RAS keys; up to 
16 keys may be provisioned and associated to different digital personalities. When a digital 
personality is not associated with a key, the radio is considered as RAS disabled when this 
personality is selected. When the digital personality is associated with a key, the radio is 
considered as RAS enabled, and uses the particular key that is associated. In this way, if the radio 
needs to operate in a different system, the radio user can select the appropriate personality with 
the corresponding key. 

When a RAS enabled subscriber transmits in Dual Capacity Direct Mode, Direct Mode, or 
Talkaround Mode, it always transmits DMR bursts. However, when receiving, it can receive both 
DMR bursts (from other subscribers) and RAS enabled bursts (from the repeater outbound). 

4.12.2 Radio ID Range Check 

In this method, only the repeater needs to be configured via CPS. Up to 64 radio ID ranges may be 
provisioned in the repeaters. For a multi-repeater system, all the repeaters need to be software 
capable of the RAS feature. However, the configuration can and only needs to be done in the 
master repeater, and is propagated to other peer repeaters automatically. Each of the radio ID 
ranges may be configured as allowed or left as un-configured. When the repeater receives a 
transmission from a subscriber, it checks whether the subscriber’s radio ID is within any of the 
allowed ranges. If it is, the repeater repeats this transmission. Otherwise, the repeater blocks the 
transmission. In this way, the transmission from unauthorized subscriber users can be blocked. 

In comparison to the RAS key authentication method, this method is much easier to use to 
configure and maintain the system, because only the repeater needs to be configured. However, 
this method has drawbacks if used alone, since the unauthorized user may figure out some 
allowed radio ID ranges by reading a valid subscriber, or analyzing the bursts over-the-air, or 
simply just guessing. The user can then easily program radios with radio IDs in the allowed 
ranges. 

Additionally, the radio ID check method can only prevent the unauthorized radio from transmitting 
to its target, but can not prevent it from receiving while the RAS key authentication method can 
perform both. For this reason, it is always recommended to use both methods together. The RAS 
key authentication provides a very robust way to prevent unauthorized repeater access and is 
extremely difficult to hack. It can be used as the primary method. 

Moreover, radio ID range check provides a flexible way to manage the system and make minor 
changes. 

Example: If the system is hosting customers A, B, and C, the system administrator could provision 
the whole system with a RAS key and operate in the RAS enabled mode. Secondly, the 
system administrator could create different radio ID ranges for these three customers. 
If for some reason, a customer, for instance, customer B needs to be excluded from the 
system temporarily, the administrator could uncheck the radio ID ranges that customer 
B's radios fall into, and the system access of the radios in the entire range will be 
blocked. When customer B needs to be allowed back into the system, the administrator 
can simply mark these radio ID ranges as allowed. 
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4.13 Data Sub-System Design Considerations 

4.13.1 Computer and IP Network Configurations 

The data applications in a MOTOTRBO system utilize IP/UDP communications, therefore it is 
necessary to design the IP configuration of the data capable devices. Although complex, it is 
important to understand how data traffic is routed from one radio to another in a MOTOTRBO 
system. This section details the different connects, and where they are used within a MOTOTRBO 
system. 

4.13.1.1 Radio to Mobile Client Network Connectivity 

As described in earlier chapters, the MOTOTRBO radio connects to a computer via USB. Once 
connected, the PC detects the connection, loads a driver, and establishes a new network interface. 
This network interface looks similar to a LAN or WLAN network interface to the PC. The radio acts 
like a DHCP server providing the PC with an IP, and setting its own IP as the default gateway. 

The Radio IP address used for this connection is programmed into the MOTOTRBO radio in the 
network settings of the CPS. The Accessory IP value is not editable in the CPS. It is derived based 
on the Radio IP. The first 3 octets are the same as the radio IP, the last octet will be the Radio IP 
value +1 (for example, if the Radio IP is 192.168.10.1, the Accessory IP will be automatically 
updated to 192.168.10.2). 

• Accessory IP - provided via DHCP to the Network Interface on the PC 

• Radio IP - used by the Radio to communicate with the PC 

- provided to the PC as the default gateway 

These IP addresses are only used for communication between the MOTOTRBO radio and the 
connected PC. It is recommended that the default values (Radio IP: 192.168.10.1, Accessory IP: 
192.168.10.2) be used in all mobile client configurations. In other configurations where multiple 
MOTOTRBO radios are connected to one PC, these values need to be different to prevent IP 
conflicts. 

If the default IP address programmed in the radio, or the one provided to the PC conflicts with 
other network interfaces on the PC, then the Radio IP should be changed using the CPS. The 
radio also allows for the default UDP ports for the ARS, Text Message and Telemetry applications 
to be changed if there exists conflict within the PC. These UDP ports will need to be updated in the 
application configuration as well. Again, it is recommended that the default values be used 
whenever possible. 

For best results, it is recommended that mobile clients do not have additional network interfaces. 
Additional static routes may need to be manually entered in the mobile client PC if multiple 
interfaces are present. It is also recommended that any applications that attempt to broadcast 
network traffic be disabled in the PC. Unnecessary traffic sent to the MOTOTRBO radio may 
cause undesired congestion over-the-air. 

The simple diagram below displays the IP connectivity between the Mobile Client and the 
MOTOTRBO radio. Note that because these IP addresses are private and only used between the 
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radio and the Mobile Client, it is recommended that they be duplicated on all Radio/Mobile Client 
configurations in the system. 



MOTOTRBO Radio 



192.168.10.1 



USB 



Radio IP = 192.168.10.1 
Accessory IP = 192 .168.10.2 
Radio IP Netmask = 255.255 .255.0 



Mobile Client on a PC 



192.168.10.2 



Default Gateway = 1 92 . 1 68 . 1 0. 1 



Figure 4-19 Connectivity between the Mobile Client and the MOTOTRBO Radio 

4.13.1.2 Radio to Air Interface Network Connectivity 

The MOTOTRBO radio must have an IP address to communicate with the MOTOTRBO network 
and other radios. The radio and the system uses the Individual Radio ID and CAI Network Address 
to construct its Radio Network IP to ensure uniqueness. The Individual Radio ID is found in the 
General Settings section of the radio CPS, and the CAI Network Address is found in the Network 
Settings section. 

A Radio ID in MOTOTRBO is a 24 bit number that can range from 1 to 16776415, and is written in 
decimal format in the CPS. In Capacity Plus and Linked Capacity Plus, the Radio ID is a 16-bit 
number (from 1 to 65535), which can be treated as a 24-bit number where the most significant 8 
bits are zero. 

For example, the Radio ID 16776415 is represented by a hexadecimal 24 bit number as FFFCDF. 
When broken into three 8 bits sections, this becomes FF, FC, and DF. This in decimal is 255, 252, 
and 223. Therefore, a radio that is configured with an Individual ID of 16776415 and a CAI 
Network address of 12 (the default), will have a Radio Network IP address of 12.255.252.223. 
Below are a few more examples (all assuming the default CAI Network address of 12): 



Unit ID = 00012045 

Convert to Hexadecimal = 002F0D 

Separate into 8 bit sections = 00, 2F, 0D 
Each 8 bit section represents 1 octet of the IP address 
Convert each section into decimal = 00, 47, 13 
Assemble IP address from conversion above = 12.A.B.C where 

A = The first 8 bit section in decimal format. In this example, A = 0 
B = The second 8 bit section in decimal format. In this example B = 47 
C = The third 8 bit section in decimal format. In this example C = 13 

The IP address for Unit ID 12045 is: 12.0.47.13 
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Unit ID = 00000100 

Convert to Hexadecimal = 000064 

Separate into 8 bit sections = 00, 00, 64 

Each 8 bit section represents 1 octet of the IP address 

Convert each section into decimal = 00, 00, 100 

Assemble IP address from conversion above = 12.A.B.C where 

A = The first 8 bit section in decimal format. In this example, A = 0 
B = The second 8 bit section in decimal format. In this example B = 0 
C = The third 8 bit section in decimal format. In this example C = 100 

The IP address for Unit ID 100 is: 12.0.0.100 



Unit ID = 05000032 

Convert to Hexadecimal = 4C4B60 

Separate into 8 bit sections = 4C, 4B, 60 

Each 8 bit section represents 1 octet of the IP address 

Convert each section into decimal = 76, 75, 96 

Assemble IP address from conversion above = 12.A.B.C where 

A = The first 8 bit section in decimal format. In this example, A = 76 
B = The second 8 bit section in decimal format. In this example B = 75 
C = The third 8 bit section in decimal format. In this example C = 96 

The IP address for Unit ID 05000032 is: 12.76.75.96 



The MOTOTRBO data applications, both in the radio and externally on the PC, perform this 
conversion to an IP address when sending and transmitting. Understanding this conversion is 
important, because it is possible to send traffic directly to the IP address of the radio, though in 
most cases this happens transparently to the user. For example, if a user creates a text message, 
and selects a user from the address book with an Individual Radio ID of 12045 (which can be 
aliased), the text message is sent over-the-air to radio 12045, and is addressed to IP Address 
12.0.47.13. When radio 12045 receives the over-the-air data message, it opens the data message 
and looks at the target IP address. Because the target IP address matches its own IP, the 
message is sent to the internal radio application. The target application is dependent on the UDP 
port number and the destination address used at the source. 

If the target of a data message is an external PC connected to the MOTOTRBO radio, the sending 
device will use an IP address with the CAI Network address plus 1 . For example, if a MOTOTRBO 
radio receives a data message for its Radio ID (12045), and the data message inside is targeted 
towards the address 13.0.47.13, it will forward that message to the connected PC. 

For ease of use, the MOTOTRBO radio has the option to be configured with a “Forward to PC” 
option, which is available in the Network settings of the radio CPS. With this option enabled, all 
messages targeted to both the 12.x.x.x and 13.x.x.x addresses are routed to the PC. It is 
recommended that this option be chosen whenever a MOTOTRBO radio is connected to the 
Application Server. The “Forward to PC” option also applies to a MOTOTRBO radio (portable or 
mobile) installed in a mobile environment, i.e. a vehicle, or in a fixed location (a mobile in a tray 
located on someone’s desk). If a radio is not connected to an external PC, the “Forward to PC” 
option should be disabled. 

It is recommended that the default value of the CAI Network address is used. If this value is 
changed, all MOTOTRBO radios in the system must be updated with the same CAI Network 
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address. Also available for configuration is the Group CAI Network address. This is used for 
broadcast data messages. Again, it is recommended that this value remain at its default value. 

Figure 4-20 displays the IP connectivity with the radio network. Also included is a simplified 
Network Address Table (NAT) that shows how the over-the-air traffic is routed to either the Radio 
or the Mobile Client. The NAT is a translation table within the MOTOTRBO radio that allows 
packets to be routed from the PC through the radio and over-the-air to the destination address. As 
previously mentioned, when the “Forward to PC” option is selected, traffic for both the 12.x.x.x and 
13.x. x.x addresses is forwarded to the PC. If disabled, that NAT table would show the 12.0.47.13 
traffic being routed to Radio IP of 192.168.10.1. This is the common configuration for MOTOTRBO 
radios that are not connected to an external Mobile Client. 




Figure 4-20 Air Interface Network Connectivity 
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4.13.1.3 Application Server Control Station Network Connectivity 

In some system topologies described in previous sections, the Application Server is required to 
service up to 16 different channels. This requires the Application Server to have a network 
connection of up to 16 control stations at the same time. Similar to the Mobile Client configuration, 
when each control station is connected to the Application Server via USB, a network interface is 
created for each. Each interface is provided the IP address configured as the Accessory IP in each 
control station. It is important that the Radio IP and the Accessory IP of the four control stations be 
different from each other to prevent IP conflict and therefore routing problems in the Application 
Server. The following IP configuration (for four control stations) is recommended: 





Radio IP 


Accessory IP/PC Network 
Interface IP 


Control Station 1 


192.168.11.1 


192.168.11.2 


Control Station 2 


192.168.12.1 


192.168.12.2 


Control Station 3 


192.168.13.1 


192.168.13.2 


Control Station 4 


192.168.14.1 


192.168.14.2 



The Individual Radio ID, and therefore the Radio Network IP Address, is very important when 
configuring the Application Server control stations. Unlike the Radio IP and Accessory IP, the 
control station’s Radio Network IP should be identical. Each control station should be programmed 
with the same Radio ID, to enable field radios to communicate with the Application Server 
regardless of what channel they are on. Although it was mentioned that MOTOTRBO radios 
should not have duplicate Radio IDs, the control stations are the exception. Because control 
stations are intended to remain on a single channel, they will always be monitoring the same 
channel. Although this Radio ID of the control stations can be any valid Individual ID, they must be 
unique, and not duplicate any non-Control Station radio ID. The suggested Radio ID for the Control 
Stations is 16448250 which converts to an easy to remember IP address of 12.250.250.250 and 
13.250.250.250. Since this Radio ID is so large, it is unlikely to be duplicated on other radios. 

It is important to note that every MOTOTRBO radio in the system that is intended to communicate 
with the Application Server must be programmed with the Application Server control station IP. 
This value must be entered for both the Automatic Registration Service (ARS) IP and the Text 
Message Server IP, which can be found in the Network settings of the MOTOTRBO radio CPS. 
Because the Application Server is the target for these messages, the 13.250.250.250 IP address 
should be programmed into every field radio. For radios that will use the Mobile Text Messaging 
Client application installed on a PC connected to the radio, the 13.250.250.250 IP address should 
also be programmed into the application. 





System Design Considerations 



363 




Figure 4-21 Application Server Control Station Network Connectivity 

As previously discussed, the control stations should be configured with the option to “Forward to 
PC” so that all data traffic the control station receives is forwarded to the Application Server. 

4.13.1.4 Control Station Considerations 

Because the control stations connected to the Application Server act as the data gateway for the 
system, the control stations themselves do not require an Automatic Registration Service (ARS) IP 
and the Text Message Server IP to be specified in their CPS Network settings. These fields should 
be left blank. In addition, the control stations should also have the ARS and GPS options disabled. 
These settings are not required for these control stations since they will be not be transmitting their 
own GPS or ARS anywhere. There is no need for these control stations to be ordered with GPS 
capability. 

Although it is possible to use the control stations connected to the Application Server for voice, it is 
highly recommended that they only act as data gateways. Since control stations (except for 
Trunked Control Stations) must remain on a single channel in order to receive the inbound data, it 
is recommended that they only contain one channel in their channel list. The Trunked Control 
Stations must have a list of all Trunked Channels. Control stations should not have scan enabled. 
This will guarantee that the Application Server is always monitoring the correct channel. Since the 
control stations will only be used for data, there is no need to program any receive or transmit 
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Groups on the channel. In other words, the Contact Name and the Group List can both be set to a 
value of None. Similarly, it is not necessary to provision any emergency settings either. 

It is important to set the TX Preamble duration of the control station to be the same as the other 
radios in the system. Since most data will be targeted towards these control stations, the proper 
preamble must be utilized. Use the same guidelines for setting this duration in the control stations 
as was used in the fielded radios. 

The admit criteria of the control station should match the settings which the other radios on the 
channel are provisioned for. The suggested setting is Color Code Free unless there are analog 
signals on the channel that the data needs to avoid. If there are analog signals on the channel that 
the data needs to avoid, then choose Channel Free instead. 

When considering other CPS options of the control station, it is a good rule of thumb to minimize 
the feature options available. This will guarantee that a user cannot accidentally place the control 
station in a state where it is not monitoring inbound data traffic. 

In almost all scenarios, it is highly recommended that a mobile radio with an AC power adapter be 
utilized as the data gateway. Although a portable radio can temporarily be used for this purpose, it 
is not recommended for long term installations. The primary reason why a mobile is recommended 
for this purpose is its ability to remotely locate the RF antenna. This is important since computers 
and their components are sometimes sensitive to RF power. Mobile antennas should be located 
away from the server itself and isolated from each other. For example, if a server has four control 
stations connected to it, it is recommended that the antennas be installed on the roof of the 
building and separated enough from each other so that they do not interfere. This is also important 
since in-building coverage is sometimes difficult to achieve. All inbound data messages will pass 
through these control stations so it is important that they are within good RF coverage of the 
repeater. Additionally, a control station is left powered on all the time. A portable continuously 
powered on in a charger is more likely to encounter power related failures. 

In conventional systems, if a control station does power off or power cycles, host-specific routes 
will be removed from the Application Server's routing tables. In these situations, the Application 
Server to radio data increases the system load as it has to be transmitted by all connected control 
stations. The actual load increase is based on the amount of Application Server to radio data. This 
load increase gradually dissipates as the radios re-register with the Presence Notifier and the 
host-specific routes are added back into the routing table. However, it is recommended to connect 
control stations to an Uninterrupted Power Supply (UPS) and are never powered off and on while 
radios are registered with the Presence Notifier. 

In trunked systems, if a Revert Control Station powers down, then the radio to the Application 
Server data increases the load on the rest of Revert Control Stations. When the failed Revert 
Control Stations power on, the load is automatically distributed on all the Revert Control Stations. If 
a Trunked Control Station powers down, then the Application Server is unable to send data to the 
radios allocated to the failed Trunked Control Station. Therefore, it is recommended to connect 
Trunked Control Stations to an Uninterrupted Power Supply (UPS) or to have redundant Trunked 
Control Stations. 

During the registration process with the Presence Notifier, the radio is instructed to refresh its 
registration at a specific time interval. The default time interval is 4 hours, though this is a 
configurable parameter in the Presence Notifier. If the time interval is decreased, more registration 
messages are sent to keep the presence availability information fresh but the system load is 
increased. If this time interval is increased, the system load is decreased but the presence 
availability information may become stale. 
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In conventional systems, once a radio is registered with the Presence Notifier, the MCDD adds a 
route to a routing table, so data messages from the Application Server to the radio are transmitted 
on the correct channel. However, if for some reason the host-specific route does not exist, then the 
Global Route is used and the data message will be transmitted from all control stations connected 
to the Application Server. This scenario increases system loading during situations where there is 
Application Server to radio data. An example of this would be network (Text Message Server) 
sourced text messages targeted towards subscribers in the field. 

4.13.1.5 Multi-Channel Device Driver (MCDD) and 
Required Static Routes 

In conventional systems, the Application Server can have up to 16 different network interfaces that 
access the radio network. In order for data messages targeted towards Radio Network IP 
addresses, such as 12.0.0.1 and 12.0.47.13, to transmit out through a network interface with IP 
addresses 192.168.11.2 or 192.168.12.2, the MCDD is required to add routes for each radio that 
registers with the Presence Notifier. For example, when radio 12045 transmits a registration 
message to its programmed ARS IP address (e.g. 12.0.47.13) on one of the channels monitored 
by a control station, the control station forwards that address to the Application Server through its 
network interface (e.g. 192.168.11 .2). The MCDD then automatically adds a route for that radio IP 
(12.0.47.13 and 13.0.47.13) to the 192.168.11.2 network interface. Once that is done, if a 
message from the Application Server needs to reach 12.0.47.13 or 13.0.47.13, the message is 
routed to the 192.168.11.2 network interface, and therefore out the correct control station and 
correct channel that has registered radio 12045. This is how data messages are sent out on the 
correct channel for a radio. 

Additional steps are required to route multicast traffic. Multicast traffic is traffic destined for radio 
groups. The routing table in the PC must be modified to allow for multicast traffic. Please see the 
MCDD install manual for details. 

Installation of the MCDD is not required in Capacity Plus. 

4.13.1.6 Application Server and Dispatcher Network Connectivity 

As described in previous chapters, the Application Server can also be configured with a LAN 
connection to the Customer Enterprise Network (CEN). A few restrictions apply to the network 
configuration between the Application Server and the Dispatch clients. In most customer cases, 
the LAN interface on the Application Server is connected to their pre-existing network. The only 
requirement is that the assigned IP of the LAN network interface must not conflict with those 
assigned to the Network Interfaces of the Control Stations. Additionally, the Application 
Dispatchers (such as Location Dispatch or Text Message Dispatch) must be connected through 
the customer CEN to the Application Server. In order for the Text Message Server to forward e- 
mail text messages, the Application Server must be connected to the Internet. If the network is 
configured to operate with a firewall, the programmed ports for the applications should be opened 
and allowed. Details of this configuration can be found in the Text Message and Location 
Application install guides. 
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4.13.1 .7 MOTOTRBO Subject Line Usage 

A MOTOTRBO Text Message is comprised of three parts: A subject line, subject line delimiter and 
body. The subject line delimiter is a carriage return (Unicode code point U+000D) and line feed 
(Unicode code point U+000A) character pair (CRLF). Therefore, anything up to the first CRLF 
within the Message is interpreted as the subject line and anything after the first CRLF is 
interpreted as the body. The subject line is left blank if there are no characters before the first 
CRLF, or if no CRLF pairs are contained in the Message. 

When e-mail text messages are received by the Application Server the e-mail subject line and 
body are converted into the MOTOTRBO Text Message subject line and body respectively. 

The maximum length of a MOTOTRBO Text Message is technically 140 characters according to 
the protocol. However, applications that support the use of Subject Lines may reduce the number 
of the effective payload. The Customer Programming Software (CPS) and the applications in the 
radios that create text messages will limit the effective payload to 138 characters. External 
applications that run on Personal Computers (PC) may further reduce the effective payload to 
provide indications that messages have been truncated (for example replacing the last character 
with a horizontal ellipse character '...'). E-mails that are longer than 138 characters will be 
truncated to fit. For example, if an e-mail is received with a 200 character subject line and a 300 
character body only the first 137 characters of the subject line plus a horizontal ellipse '...' at the 
end is converted into the MOTOTRBO Text Message and the rest of the e-mail will be discarded. 
In another example, if an e-mail is received with a 100 character subject line and a 300 character 
body, then the 100 characters of the subject line and the first 37 characters of the body with an 
ellipse added at the end will be converted into the MOTOTRBO Text Message format. 

Radios replying to messages preserve the original message's subject line. In this manner, external 
services and solutions that use e-mail for communication can use the content of the subject line to 
correlate between e-mails that are sent and e-mails that are received. For example, an automated 
service could send out an e-mail with a unique ID string in the subject line. If a radio replies to the 
message, it preserves the subject line with the unique ID string and the automated system can use 
the address and subject line of the message to know that a specific unit had replied to a specific 
message. 

The number of characters allowed in a reply by a radio are equal to 138 characters minus the 
number of characters in the subject line. For example, if an e-mail is sent with a 30 character 
subject line and a 100 character body, the entire message will be received by the radio. When the 
radio replies to the message the subject line is automatically preserved leaving 108 characters for 
the radio to reply with. 

MOTOTRBO Text Messages that originate from the front panel of radios or the Text Messaging 
Client via the Application Server and destined for e-mails addresses will contain blank subject 
lines. Radios do not have the capability to create or modify a subject line from the front panel. The 
CPS does not have the capability to create a subject line. 

4.13.1.8 MOTOTRBO Example System IP Plan 

The following diagram is an example of the information contained in the previous sections. This 
diagram shows a configuration of multiple digital repeaters at a single site functioning in 
conventional repeater mode. It should be used as a guideline for configuring a MOTOTRBO 
System. 
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4.13.1.9 Application Server Network Connection Considerations 

Besides being connected to the radio network via the control station(s), the Application Server 
may also be connected to another network such as the Internet. When operating under these 
conditions, it is important to consider the following: 

• Disable all protocol support except for TCP/IP. 

• Ensure networking application messages are routed to the Ethernet connector or the 
wireless network interface and not to the network connection to the control station(s). 

Sometimes, the Application Server is connected to the radio network via the control station(s). 
When operating under these conditions, it is important to remember that all network traffic 
generated by the Application Server will be routed to the control station(s). In order to optimize the 
radio network, these messages should be kept to a minimum. The following items should minimize 
the amount of network traffic being routed to the control station(s). 

• Disable all protocol support except for TCP/IP. 

• Turn off the PC wireless network interface. 

• Do not launch any networking application (i.e. internet browser, e-mail, etc.). 

• Disable all automatic updates for network applications that are running in the 
background, such as virus updates, IM updates, Windows updates, etc. 

4.13.1.10 Reduction in Data Messages (When Radios Power On) 

When a radio powers on, up to eight data messages are exchanged between the radio and the 
Server. This may cause congestion in the channels if many radios are powered on within a short 
duration. The situation worsens if one or more data messages are lost due to the overflow of 
queues or poor RF transmission conditions. A loss of message causes multiple retries both at the 
Data Link and Application layers. These additional messages cause further congestion of the data 
channels. 

An example of a use case where a set of mobile radios are powered on within a short period is a 
Bus Depot. Buses have mobiles to facilitate the tracking of buses from a central location. The 
MOTOTRBO mobiles have built-in GPS receivers that send the location of a bus periodically. 
Generally, the buses leave the depot within a short period of each other. All the mobiles in the 
buses may power up within this period, jamming the channels and hence delaying the registration 
of mobiles. In this case, the locations of buses are not available at the central location until the 
registration process completes successfully. 

MOTOTRBO provides two mechanisms to reduce the number of data messages triggered by 
powering a radio. The total reduction is up to one fourth of the original number of messages 
exchanged between a radio and the Server, i.e. the number of data messages reduces to two. The 
two mechanisms are described below. 

The presence of a radio triggers a Text Messaging application to send a message to the radio. 
This message is called the Service Availability message and it contains the IP address of the Text 
Messaging application and the services offered. To reduce the number of Service Availability 
messages, a customer should do the following: 
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• Pre-configure the radio with the IP address (as seen by the radio) of the Text Messaging 
Server using CPS. 

• Configure the Text Messaging application not to send the Service Availability message 
when the radio powers-on. 

In the absence of the Service Availability message, a radio uses its pre-configured values for the 
IP address of the Text Messaging Server. If the Text Messaging Server sends the Service 
Availability message, then the radio overwrites its values with the values from the received 
message and stores it persistently. The persistent storage of IP address avoids the need to send 
the Service Availability message if the IP address of the Text Messaging application remains the 
same. Upon change of the IP address, a customer should enable the Text Messaging application 
to send the Service Availability message. Once all the radios have received the Service Availability 
message, the customer can disable the sending of Service Availability messages. 

The presence of a radio also triggers the Location Application to send two requests to the radio: 
one for location update on emergency and the other for periodic location updates. To reduce the 
number of messages, the radio saves the requests persistently and the Location Application 
allows the customer to enable/disable the transmission of the requests, when a radio registers its 
presence. It is not possible to configure requests in a radio using CPS. A radio without requests 
should undergo an initialization process. During initialization, the Location Application sends the 
required location requests to the radio. A radio needs to be initialized only once. If a customer 
needs to change the IP address or the UDP port number of the Location Application, then the 
Location Application should delete the requests from all the radios before it changes its address. 
As it is not always possible to satisfy the above condition, MOTOTRBO provides an alternative to 
delete all the requests in a radio using the CPS. 

NOTE: This feature was introduced in software version R01.05.00. Text Messaging and Location 
Applications compatible with older software versions may not support this feature. All 
customers are encouraged to verify their applications for feature compatibility. 

4.13.1.11 Optimizing for Data Reliability 

It is important to exercise care when optimizing voice quality in two way radio systems such as 
MOTOTRBO. This commonly consists of verifying if the RF signal, both inbound and outbound, is 
adequate enough in the desired areas to provide an acceptable level of voice quality. The radius 
from the transmitting tower that yields the acceptable level of voice quality is often referred to as 
the coverage of the system. On the fringe of this coverage, voice quality may experience 
degradation due to errors. 

The human mind (with help from the vocoder) can mitigate the loss of a few random syllables of 
speech and still understand the intended meaning of a spoken sentence. However, when 
attempting to deliver data to the radios on the fringe, a data application cannot usually just ignore a 
few errors and still understand the full message. 

It is important to understand that there is a probability that data incurs an uncorrectable error when 
received at particular signal strength, known as Block Error Rate. As the amount of data to be 
transmitted increases, there is an increasing probability the data message has an error. Because 
of this, it is more difficult to deliver a long data message without errors to the fringe than a short 
data message. Another way of looking at this is a short data message can be delivered farther 
away without errors than a long data message. 

To optimize data for reliability, the user should: 
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• Use confirmed individual data 

• Minimize application data payload size 

• Disable UDP header compression 

• Enable enhanced channel access 



4.13.1.11.1 Use Confirmed Individual Data 



MOTOTRBO radios can be configured to send individual data messages confirmed or 
unconfirmed at the link layer. Group data messages (those targeted towards talkgroups) are 
always sent unconfirmed. If sending long data messages, it is always recommended to use 
individual confirmed messaging to achieve the best reliability. 

When data is sent unconfirmed, the radios send their data messages to the target without any link 
layer confirmation that it arrived successfully. When sending very short data messages, such as 
GPS, this method may be acceptable since short messages have a lower probability of arriving 
with uncorrectable errors. However, as previously described, long data messages have an 
increased probability of failure at the fringe. It is important to note that sending long unconfirmed 
data messages multiple times at the application layer only slightly increases the overall probability 
of success, since each retry is as long as the first attempt, and therefore has the same probability 
of failure. 

When data is sent confirmed, the radios send their data messages to the target with confirmation 
that each segment within the data message arrived successfully. If one or more of the segments 
within the data message was received with an uncorrectable error, the target responds to the 
source requesting only the segments that had uncorrectable errors be resent. This is referred to as 
selective retries. Because retries are shorter, they have fewer segments than the original attempt 
and the probability of success increases. This increases the overall success rate of delivering long 
data messages to radios in the fringe. 

NOTE: In software versions R02.20.00, an additional enhancement was made to the selective 
retry mechanism that increases the probability of success of individual confirmed data 
messages even more. Therefore, it is recommended to upgrade for best reliability. 

4.13.1.11.2 Minimize Application Data Payload Size 

Some data applications may allow the size of their data messages sent over-the-air to be 
configured. This is sometimes referred to as their message fragmentation size. For best reliability, 
it is recommended to utilize a message size less than, or equal to 256 bytes over-the-air. Data 
messages longer than 256 bytes may have decreased coverage even when utilizing confirmed 
messaging. 

4.13.1.11.3 Disable UDP Header Compression 

MOTOTRBO radios can be configured to perform UDP header compression. This feature reduces 
the 28 byte UDP/IPv4 headers to four or eight bytes, but it requires an extra link layer header. The 
net effect is the saving of 60 milliseconds for confirmed messages, or 120 milliseconds for 
unconfirmed messages. For short data messages, such as GPS, this approximately reduces the 
transmission time by 10% to 20%. However, for longer data message (256 bytes), the savings in 
transmission time is very small and the extra header can decrease reliability in some instances. 
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Therefore, for best reliability, it is recommended to not utilize UDP header compression when 
transmitting long data messages since the decrease in reliability is not worth the 60 to 120 
milliseconds savings in delivery time of a long data message that may take seconds to complete. 

4. 1 3. 1 . 1 1 .4 Enable Enhanced Channel Access 



MOTOTRBO radios can be configured to utilize Enhanced Channel Access. Enhanced Channel 
Access can minimize the number of collisions between radios transmitting data by performing a 
high speed handshake with the repeater. The high speed handshake takes approximately 120 
milliseconds to complete. Collisions can result in both data messages becoming corrupt and 
therefore requiring each to retransmit. When ECA is enabled on all radios, collisions are detected 
and mitigated by allowing one radio to gain access to the channel, while the other is held off. 
Therefore, it is recommended to enable ECA for best reliability. 

4.13.1.12 Optimizing for Data Throughput 



If utilizing data applications that only send short data messages to radios in great RF coverage, the 
user might wish to optimize for data throughput since reliability is not a primary concern. An 
example of this might be the GPS. Rather than utilizing extra bandwidth sending short messages 
reliably, it may be more useful to minimize the size of the message even more so that messages 
can be sent more often. The loss of one GPS message is of little concern if another updated 
message shortly follows. 



To optimize data for throughput when sending short messages in great RF coverage, the user 
should: 



• Use unconfirmed individual data 

• Enable UDP header compression 

• Disable enhanced channel access 

• Disable scanning and lower scan preamble 

• Minimize battery saver preambles 



4.13.1.12.1 Unconfirmed Individual Data 



MOTOTRBO radios can be configured to send individual data messages confirmed or 
unconfirmed at the link layer. Group data messages (those targeted towards talkgroups) are 
always sent unconfirmed. If sending short data messages, and if optimizing for throughput, the 
user should consider using unconfirmed messaging. 

When data is sent unconfirmed, the radios send their data messages to the target without any link 
layer confirmation that it arrived successfully. If the message size is less than 144 bytes (in 
repeater mode) or 48 bytes (in Talkaround mode), then unconfirmed data messages have lower 
transmission time over-the-air than confirmed data messages. 

Short messages have a low probability of arriving with unrecoverable errors. However, as 
previously described, long data messages have a higher probability of arriving with unrecoverable 
errors. Therefore sending long messages unconfirmed is only successful to radios within great RF 
coverage. It is also important to note that sending long unconfirmed data messages multiple times 
at the application layer only slightly increases the overall probability of success since each retry is 
as long as the first attempt, and therefore has the same probability of failure. 
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NOTE: If there are radios with software versions prior to R01 .05.00 in the system, and receiving 
individual data messages from newer radios, the newer radios should be configured to use 
confirmed individual data messages only, to avoid interoperability issues. 

4.13.1.12.2 Enable UDP Header Compression 

MOTOTRBO radios can be configured to perform UDP header compression, which reduces the 28 
byte UDP/IPv4 headers to four or eight bytes, but requires an extra link layer header. The net 
effect is the saving of 60 milliseconds for confirmed messages or 120 milliseconds for unconfirmed 
messages. For short data messages, such as the GPS, this approximately reduces the 
transmission time by 10% to 20%. If sending short data messages in great RF conditions, and if 
optimizing for throughput, one should consider utilizing UDP header compression. 

A control station or a radio sends compressed data messages only if the feature is enabled, but 
processes compressed data messages even if the feature is disabled. A non-MOTOTRBO radio or 
a legacy MOTOTRBO radio with software versions prior to R01 .05.00 cannot receive compressed 
data messages and therefore this feature should be enabled in a control station only if all the 
radios in the system are MOTOTRBO radios with software versions R01.05.00 or later. This 
feature can be enabled in a control station or a radio selectively for data messages transmitted to 
one or more applications, that is based on the destination UDP port. 

4.13.1 .12.3 Disable Enhanced Channel Access 

MOTOTRBO radios can be configured to utilize ECA. The high speed handshake takes 
approximately 120 milliseconds to complete. If optimizing for throughput, one should consider 
disabling ECA. 

Enhanced Channel Access can minimize the number of collisions between radios transmitting 
data by performing a high speed handshake with the repeater. Collisions can result in both data 
messages becoming corrupt and therefore requiring each to retransmit. When ECA is disabled, 
high volume asynchronous messages from radios collide often, and if utilizing confirmed 
messaging results in both devices retransmitting, which ultimately results in lower throughput. If 
utilizing a synchronized data delivery method, for example a request and reply method from a 
centralized server, collisions may not occur as often. 

4.13.1.12.4 Disable Scanning and Lower Scan Preamble 

MOTOTRBO radios can be configured to utilize a data preamble, primarily utilized to reach 
scanning radios. The default value is 960 milliseconds, but can be configured substantially higher. 
When utilizing unconfirmed messaging, the data preamble adds to the overall length of each 
message. If utilizing confirmed messaging, the data preamble is added to retransmissions only. 

If optimizing for throughput, one should consider disabling scan and lowering the scan preamble to 
zero. If there are scanning radios remaining, and a data preamble of the transmitting radio is set to 
zero, the scanning radios will most likely not receive the message. 

If only sending data from fielded radios to a centralized data application, it is presumed the control 
stations that are receiving the messages are not scanning. Therefore data preambles are not 
required on fielded radios. 
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4.13.1.12.5 Minimize Battery Saver Preambles 

MOTOTRBO radios can be configured to send battery saver preambles. These preambles are 
used to reach radios that have battery saver enabled. If optimizing for throughput, one should 
consider disabling battery saver and disabling sending battery saver preambles. For a typical 
location message, this approximately reduces the transmission time by 10%. 

If utilizing all mobiles, battery saver, and battery saver preambles are not required. 

NOTE: To avoid interoperability issues, it should be configured in the system that either all or none 
of the radios send battery saver preambles. If there are radios with software versions prior 
to R01 .05.00 in the system, they will always be expecting battery saver preambles, 
therefore either all the radios in the system should be configured to send battery saver 
preambles, or all upgraded to a newer release. 

4.13.1 .13 Data Revert Channels for Capacity Plus 
and Linked Capacity Plus 

MOTOTRBO in Single Repeater and IP Site Connect modes support the GPS Revert feature. In 
Capacity Plus and Linked Capacity Plus, MOTOTRBO extends the GPS Revert feature to include 
all types of data messages transmitted to the Application Server. The Data Revert Channel feature 
allows system operators a configurable option to offload all the data messages from radios to a 
Server onto programmed digital channels (called Data Revert Channels). Data Revert Channels 
are different from Trunked Channels. Examples of data messages sent from radios to a Server are 
registration messages, location responses, text messages to the Server, and their over-the-air 
acknowledgements. 

Data Revert Channels are exclusively used for transporting data packets. They are also especially 
useful for transporting location responses. They are not used for voice communication. However, 
Trunked Channels are not exclusively used for transporting voice. Data messages from one radio 
to another, and from an Application Server to radio(s) are always sent via Trunked Channels. As 
Data Revert Channels offload most of the data communication from Trunked Channels, they 
facilitate more voice communication over these channels. 

There must be a Revert Control Station for each Data Revert Channel. If one channel of a repeater 
is used as a Data Revert Channel, then the other channel of the repeater is also used as a Data 
Revert Channel. Thus, the Revert Control Stations are always in a pair. The revert channel’s 
Control Station receives a data message from a radio, returns acknowledgement to the radio (if 
required), and forwards the message to the Application Server connected to the control station. 
The Revert Control Station then operates in single repeater mode but does not understand the 
trunking messages (e.g. System Status CSBK) and does not tune to the Rest Channel. The revert 
channel’s control stations stay tuned to its assigned revert channel. 

In the GPS Revert feature (single repeater or an IP Site connect), a radio is programmed with only 
one revert channel. However, for Data Revert in Capacity Plus and Linked Capacity Plus, a radio is 
programmed with a list of the revert channels. This allows a radio to look for more than one 
channel (up to 4 channels) for transmission. This increases the probability of a successful 
transmission. Additionally, this increases the reliability of the transmission when a revert repeater 
is down as the radio automatically looks for the next repeater. A radio uses the revert channels in a 
round-robin fashion, distributing the load of data transmission fairly between the channels. 
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There is at least one Trunked Control Station, which is used by the Application Server to send a 
data message to a radio. A Trunked Control Station has the Capacity Plus or Linked Capacity Plus 
software installed and follows the Rest Channel as the Rest Channel changes. There may be 
more than one Trunked Control Stations in the system. The required number depends on the 
number of messages from the Application Server to radios. It is recommended to use a Trunked 
Control Station for every 20 messages, of 50-byte or character size payload, per minute. 

To avoid misconfiguration, the CPS does not allow programming a trunked and revert channels in 
the same list. The CPS only performs channel check but not actual frequency check. Thus, while 
configuring the frequencies for the system, caution must be exercised to not use the same 
frequency for a revert channel and a Trunked Channel. 

A Capacity Plus or a Linked Capacity Plus system can have more than one Trunked Control 
Station, therefore a fair distribution of data packets among the Trunked Control Stations is 
required. For a simple way to achieve the fair distribution, follow these rules: 

1. The radios should be grouped into ‘n’ sets, where ‘n’ is the number of Trunked Control 
Stations. 

2. Each set of radios is associated to a Trunked Control Station. 

3. For each set of radios, it is required to make one or more entries in the IP Routing Table of 
the Application Server such that a data packet transmitted to a radio is routed to the port of 
the Trunked Control Station associated with the set of the radio. 

The IPv4 address of the Server (as seen by a radio) is derived from the radio ID of the Control 
Stations. This is shown in Figure 4-23. The example has two Revert Control Stations (shown in 
blue) and two Trunked Control Stations (shown in green). The example assumes that the IDs all 
radios are within {1 ..255}. They have been divided into two sets of {1.. 126} and {127. .255}. 

NOTE: 

1. Say a group of radios is defined as {n..m} where ‘n’ and ‘m’ are the lowest and highest IDs of 
the radios respectively, and there are two Trunked Control Stations. The radios should be 
divided into two sets of radios, say {n..p} and {p+1..m}. Here, ‘p+T is a power of 2 (e.g. 4, 8, 
16,32,64,...). 

2. The sets of radios are non-overlapping. This means a radio is a member of one and only 
one set. 

Multiple groups can be allocated to a Trunked Control Station by having one entry per group in the 
IPv4 routing table of the Server. 

For more details on how to configure the IP routing table, refer to the spreadsheet file 

MOTOTRBO Text Messaging Installation Procedures for Supporting MOTOTRBO Capacity 
Plus.xls. (available only to customers of Motorola's MOTOTRBO Text Messaging application) 
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Figure 4-23 An example showing IPv4 addresses in a Capacity Plus configuration with Data Revert 
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4.13.2 Data Application Licensing Considerations 

The Presence Notifier and MCDD is included with each Text Messaging Server as well as each 
Location Server. The Presence Notifier, Text Messaging Server and Location Services Server can 
all be installed on one physical server. 

The Location Services base package consists of a Fixed Client and Server plus one (1) map. The 
base package includes support for up to 10 radios. Additional fixed clients can be purchased on a 
single user basis. A mobile client is not available. Additional radio licenses can be purchased in 
groups of five (5) radios. 

The Text Messaging base package consists of a Fixed Client and Server. The base package 
includes radio licenses for up to 10 radios. Additional fixed clients can be purchased on a single 
user basis. Additional mobile clients can also be purchased on a single user basis. The mobile 
client comprises of software installed on a PC. Additional radio licenses can be purchased in 
groups of five (5) radios. 

Typically, one text message dispatcher is required per functional group. Multiple text message 
dispatchers can be used if the functional group is large or if there are unique communication 
requirements. The text message dispatchers should have the users of their functional group in 
their address book. If the dispatcher needs to dispatch text messages outside of the function 
group, they can use the manual address entry feature of the Text Message Client. 
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4.13.3 Mobile Terminal and Application Server Power Management 
Considerations 



There are some considerations that have to be taken with regards to the Power Management 
settings on a PC being used for either a Mobile Terminal or Application Server. 

It is recommended that the power management settings of the Application Server and Mobile 
Client be disabled. Specifically the System Standby and System Hibernation settings should be set 
to Never. 

It is crucial that the Application Server and Mobile Terminal always be active so that they can 
transmit and receive data messages. If the Application Server or Mobile Client is allowed to enter 
System Standby or System Hibernation, it will not respond to received data messages. The 
radio(s) connected to the Application Server or Mobile Client will then queue the data until 
messages fail to be delivered. It will be the responsibility of the sending device to retry the failed 
message. A user will need to “awaken” the Application Server or Mobile Client before it will accept 
messages again. 

4.13.4 MOTOTRBO Telemetry Connection Details 

For more details about the telemetry GPIO pin assignments, please refer to the MOTOTRBO 
Telemetry ADK Guide available on the MOTODEV Application Developers website. 

https://mototrbodev.motorolasolutions.com 

4.13.5 MOTOTRBO Network Interface Service (MNIS) and Device 
Discovery and Mobility Service (DDMS) 

This section documents system design considerations related to MNIS and DDMS deployment in 
a MOTOTRBO system. It also covers MNIS and DDMS features and capabilities, data application 
deployment considerations and considerations for migrating from control stations to MNIS based 
deployment. The DDMS is formerly known as the MOTOTRBO Presence Notifier. 

The following basic considerations are important and must be noted: 

• The MNIS application currently does not support voice and CSBK calls. 

• If data support with MNIS and DDMS is desired, ensure that the data application 
supports MNIS and DDMS. 

• MNIS and DDMS configuration details can be found in their respective online and 
context help. Additional information can also be found at the MOTOTRBO ADP portal. 

• Discuss with third-party data application vendor for any questions related to their 
application support of MNIS and DDMS. 
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4.13.5.1 MNIS and DDMS Operation Overview 

The MNIS is a Windows service application, which supports data applications without requiring 
control stations. MNIS acts as a gateway to the radio system for the data applications. It connects 
with the radio system over an IP network and utilizes the repeaters to transmit and receive data 
messages between Data Application Servers and MOTOTRBO radios. 

The MNIS has an identifier and MNIS Application ID. The ID is configured in the MNIS using the 
configuration GUI. The ID is used by the MNIS to receive and transmit on the radio network. The 
MNIS Application ID is used whenever the radio needs to communicate with the data application 
or vice versa. For example, the ARS and TMS Radio ID fields in the radios are configured to the 
MNIS Application ID. The data message from the radios to the ARS or TMS applications has the 
MNIS Application ID as the destination of the message. Likewise, the data message from ARS or 
TMS applications to the radios has the MNIS Application ID as the source of the message. The 
MNIS Application ID is identical to the radio ID of the control stations. The fielded radios should not 
be configured with the radio ID that is same as the MNIS Application ID. 

The MNIS is configured with the Master repeater’s IP address, which it uses to discover and 
connect with the repeater system. Upon connection with the repeaters, the MNIS informs the 
repeaters of its MNIS Application ID. When a fielded radio transmits a data message with the 
destination address of the MNIS Application ID, the repeater assembles the blocks of the data 
PDU received over-the-air and forwards to the MNIS. The MNIS in turn forwards the data message 
to the data application. When a data application sends a data message to a fielded radio, the 
MNIS forwards them to a repeater for transmission over-the-air. 

The radio’s presence and mobility management is handled separately by the MOTOTRBO Device 
Discovery and Mobility Service (DDMS) application. The DDMS can be deployed with either the 
MNIS or control station. 

The MNIS and DDMS have multiple interfaces, as shown in Figure 4-24. The interfaces are 
described in the following sections. 
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Figure 4-24 MNIS and DDMS Interface Overview 

4.13.5.1.1 Network Application Interface 

The MNIS connects with the repeater system using the link establishment procedure of the 
repeater system. This requires the MNIS to be configured with the Master repeater’s IP address 
and UDP port number. Upon connection with the Master repeater, it discovers the IP addresses 
and port numbers of all the repeaters in the system. Then, the MNIS establishes the link with the 
repeaters in the system. 

Upon connection with the repeaters, the MNIS uses the repeater’s Network Application Interface 
and underlying services to support data transmit and receive through the repeaters. The MNIS 
encapsulates the applications UDP/IP data packet in the Network Application Interface packet and 
sends it to the repeater. The repeater transmits the data message over-the-air. Likewise when the 
repeater receives a message meant for the MNIS, it encapsulates the message in the Network 
Application Interface’s data packet and sends it to the MNIS. The link establishment and Network 
Application Interface procedures are transparent to the data application. 
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If using MNIS, all the repeaters in a system (IPSC, Capacity Plus, or LCP) are required to have the 
Network Application Interface - Data option enabled. If using MNIS with a single site repeater, the 
same option in the repeater must be enabled. Enabling this option in the repeaters can be done 
using the CPS. 

4.13.5.1.2 Data Application Interface 

The MNIS supports the standard UDP/IP based interface for data communication with the radio. 
This interface is similar to the data communication via control stations. 

In a control station deployment, data messages from the application are routed by the IP stack of 
the PC to the network adaptor of the control station. The control station then receives the data 
message and transmits over-the-air to the radio. The data message received by the control station 
from the over-the-air is sent to the IP stack of the PC from its network adaptor. The IP stack of the 
PC routes the data message to the application. 

When utilizing the MNIS the data messages from a data application are routed by the IP stack of 
the PC to the network adaptor (also called the tunnel adaptor) of the MNIS. The MNIS forwards the 
data message to the repeater for transmission over-the-air. The data message received by the 
repeater is sent to the MNIS. The MNIS sends the data message to the IP stack of the PC from its 
tunnel adaptor. The IP stack of the PC then routes the data message to the data application. 

4.13.5.1.3 DDMS Watcher Interface 

The DDMS watcher interface is an interface for applications, including the MNIS, to obtain the 
presence and mobility information of the radios from the DDMS. The DDMS maintains both the 
radio presence and mobility information. It provides an interface to the MNIS, and the data 
application to get notifications on change in the presence or mobility information of specified 
radios. 

• Presence Information - The MNIS forwards the radio ARS message to the DDMS, which 
updates the radios presence. The DDMS notifies data applications that have subscribed for 
presence through the watcher interface. 

• Mobility Information - The radio’s mobility is the channel or site where the radio is present. 
The MNIS uses the mobility information to route outbound data messages for transmission. 

The MNIS determines the radio mobility information based on the channel and the site from where 
the ARS is received. The watcher interface is then used to input the mobility information in DDMS. 
The DDMS notifies mobility updates to an application, including the MNIS, that has subscribed for 
radio’s mobility information. 
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4.13.5.1.4 Flow 



Figure 4-25 shows the flow of messages to facilitate the Location Service with the MNIS and 
DDMS deployment. 



1. Subscription 

2. Registration 




1 . The location application subscribes for the radio’s presence information with DDMS. 

2. Upon power-up, the radio transmits an ARS message to register with the DDMS. The 
ARS message is then received by the repeater and sent to the MNIS. The MNIS routes 
the message to the DDMS. The DDMS updates the radio’s mobility information based on 
the channel from where the ARS is received. 

3. The DDMS notifies the location application of the presence of the radio. 

4. The location application sends a location request which gets routed to the MNIS. The 
MNIS refers to the radio’s mobility information to determine where to transmit the location 
request and routes to the appropriate repeater. The repeater transmits the location 
request to the radio. 

5. The radio transmits its location updates, which are received by the repeater and sends to 
the MNIS. The MNIS routes the location updates to the location application. 

4.13.5.2 System Topology with MNIS 

The MNIS supports MOTOTRBO digital - Single Site and IPSC, Capacity Plus and Linked 
Capacity Plus systems. It can connect with: 

• Up to eight (8) conventional repeater systems - any combination of Single Site or IPSC 
with wide or local area channels. It is recommended that the total number of logical 
channels 1 of the repeater systems does not exceed 32, or 

• One Capacity Plus system, or 

• One Linked Capacity Plus system. 



1 . A conventional repeater system has multiple logical channels. A single site digital repeater system has 
two logical channels (slots). 
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• An IPSC repeater system has: 

• Two wide area logical channels, or 

• A combination of wide and local area logical channels 

4.13.5.2.1 Multiple Conventional Systems Topology 

Figure 4-26 shows an example of a topology with multiple IPSC and Single Site systems. The 
radios share the same data applications. Multiple data applications such as Location, Text, 
Telemetry, and others, can be deployed. In this system configuration, the radios must have unique 
radio IDs across all repeater systems. The ARS and TMS Server addresses must be set to the 
MNIS Application ID. 




• In this deployment, with multi-channels, the radios must have ARS enabled. The radios’ 
mobility is updated based on the channel from where the ARS is received. The MNIS 
uses the mobility information to send outbound messages from the data application to 
the radio. Without mobility information, the MNIS transmits the data message to all 
connected channels. 

• The location application’s address is not configured in the radios. The radio determines 
the address from the source address field of the location request message. Since the 
location request is sent from the MNIS, it carries the MNIS’ Application ID in the source 
address field. 
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• The GPS Revert Channels (or Enhanced GPS Revert Channels) can be configured as 
local or wide area. However, it is highly recommended to configure the GPS Revert 
Channel to local. There is no reason to have wide area GPS revert channels, if utilizing 
the MNIS. Wide area for GPS Revert was required so that the data could be routed to 
one set of control stations over-the-air. With the existence of the MNIS, the data 
received on local channels is routed to the data application over the network. In general, 
local GPS Revert Channel increases the GPS capacity, since one wide area channel 
can be replaced by numerous local channels. 

4.13.5.2.2 Capacity Plus System Topology 

The figures below show examples of topologies for a Capacity Plus system. The MNIS can be 
deployed on the same LAN as the repeaters, where remote connectivity is not required. 
Alternatively, it can be deployed remotely from the repeaters when remote connectivity is required. 
This is illustrated in Figure 4-28 
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Figure 4-27 Capacity Plus System with MNIS Deployed in the Same LAN as the Repeaters 
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Figure 4-28 Capacity Plus System with MNIS Deployed Remotely 
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4.13.5.2.3 Linked Capacity Plus System Topology 

The figures below show examples of topologies for a LCP system with MNIS deployed on a 
separate subnet than the repeaters. 
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Figure 4-29 Linked Capacity Plus System with MNIS 



NOTE: The Data Revert Channels (or Enhanced GPS Revert Channels) can be configured as 
local or wide. However, it is recommended to configure them to local. There is no reason 
to have wide area data revert channels, if utilizing MNIS. Wide area data revert was 
required so that the data could be routed to one set of control stations over-the-air. With 
MNIS, the data received on local channels is routed to the data application over the 
network. In general, local data revert channel increases the bandwidth since one wide 
area channel can be replaced by numerous local channels. 
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4.13.5.2.4 System Topology with Multiple MNIS 

In a system where two or more agencies are sharing the radio system, then the agencies can have 
their independent MNIS deployments. Up to four (4) MNIS can be deployed with the repeater 
system whether it is a conventional system or systems, Capacity Plus or Linked Capacity Plus 
systems. Figure 4-30 shows an example of topology with two MNIS deployed in a LCP system. 
The radios can be configured to communicate with either MNIS-1 or MNIS-2. 
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Figure 4-30 Linked Capacity Plus System with Two MNIS 

NOTE: Once the Network Application Interface for data is enabled at the repeater, then multiple 
MNISs can be connected to it. 
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4.13.5.2.4.1 Number of Repeater Sites with Multiple MNIS Deployment 

One MNIS can be deployed on an IPSC or LCP system with up to 15 repeater sites. If two or three 
MNIS are deployed, then the number of repeater sites should be restricted to just 14. The 
restriction is meant to prevent excess loading on the repeaters due to the maximum number of 
system sites and additional MNISs. 

4.13.5.2.5 Topology with MNIS and Control Stations 

The MNIS and control stations can be deployed on the same repeater system. Figure 4-31 shows 
an example of topology with the MNIS and control stations deployed in a Capacity Plus system. 
The radios can be configured to communicate with either the MNIS, or the control station. 
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Figure 4-31 Capacity Plus System with MNIS and Control Stations 



4.13.5.3 Data Applications and MNIS Deployments 



There are a couple of options for data applications and MNIS deployments. The deployment can 
either be with: 

• MNIS and data applications deployed on the same computer, or 

• MNIS and data applications deployed on different computers, or 

• A combination of the first two. 

The data applications and MNIS deployed on the same computer is the simplest deployment. 
However, the computer must meet the total performance requirement for MNIS, DDMS, and other 
data applications. For details, refer to the “MNIS and DDMS Computer Specifications” section. 

The data applications and MNIS can be deployed on different computers, for several reasons: 
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• The computer does not meet the total performance requirement for the MNIS, DDMS 
and data applications. 

• The data application vendor does not require the application to be deployed with other 
applications. 

• The data application is not a Windows application. 

• Unstable data application can be prevented from interfering with the MNIS operation. An 
example would be an OS crash. 

The MNIS has data message port forwarding support to facilitate deployment of data applications 
and MNIS on separate computers. Figure 4-32 illustrates this. 
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Figure 4-32 Application and MNIS Deployed on Separate Computers 



The MNIS needs to be configured to forward location and text data messages from the radios to 
the computers with Location and Text applications. The UDP port type configured is source port 
because the radios’ standard data services ports are fixed (with Location = 4001 and Text = 4007). 
The MNIS also allows selection of the destination port type. This option can be used for non- 
standard data services, such as third-party raw data. Configuration of port forwarding is not 
required when the data application is deployed on the same computer as the MNIS. Therefore, no 
configuration of port forwarding is specified for the ARS data since the DDMS and MNIS are on the 
same PC. 



The computers with the Location and Text applications require IP routes to be configured to route 
messages from the data application to the computer with the MNIS. Figure 4-32 shows a route for 
data messages belonging to system CAI network IDs = 12, 13 and 224. When the data 
applications and MNIS are on different subnets, then it must be ensured that the CAI network 
addresses are routable between subnets. One common way for doing this is to use a VPN. The 
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computer with the MNIS requires the IP routing enabled. This allows the data message from 
applications to be internally forwarded to the tunnel adaptor of the MNIS. 

It is recommended that the DDMS be deployed on the same computer as the MNIS. This reduces 
the IP traffic on the network. The data applications are configured with the IP address of the 
computer with the DDMS application and the DDMS watcher interface port. 

When the data applications, MNIS and DDMS are deployed on the same computer, take note of 
the following: 

• Configuration of port forwarding in the MNIS is not required. 

• Route paths for CAI network are not required to be added manually as MNIS sets them 
automatically. 

• Enabling IP forwarding is not required. 

4.13.5.4 Mobility Management and Individual Data Transmission 

The DDMS, when deployed with MNIS tracks the radios’ mobility. The DDMS updates the radios’ 
mobility based on the channel or site, from where the ARS message from the radio is received. 
The MNIS and any other data application can subscribe with the DDMS for radio mobility 
information. The DDMS provides radio mobility information upon subscription, and subsequently 
when the mobility information gets updated. The DDMS stores the mobility information in 
persistent memory so that it is available following DDMS or MNIS power cycles. The mobility 
information is retained even when the radio becomes absent. 

Upon power up, the MNIS subscribes with the DDMS to receive the mobility information. Following 
initial notification, it continues to receive mobility updates from the DDMS. The MNIS uses the 
radios’ mobility information to route the outbound data from the data application. Only individual 
data messages are routed in this manner. 

In an IPSC system, the MNIS is aware of the local and wide area channels. If a radio is known to 
be present on a local channel, then the data message is transmitted only on that local channel. If 
the radio is known to be present on the wide area channel, then the data message is transmitted 
on the wide area channel. If the radio is absent, but its mobility information is known based on a 
previous registration, then the MNIS routes the data message based on the last known mobility 
information. If the radios’ mobility information is not known, then the message is routed to all the 
channels of the system, except the channels selected as data revert. Sending individual data 
messages over-the-air on all channels wastes bandwidth. Therefore, it is always recommended 
that the ARS feature is enabled. 

In a Capacity Plus system, outbound data messages are always routed to the Rest Channel of the 
repeater. No data messages are routed to the revert channels. 

In an LCP system, a radio’s mobility is the site where the radio sends its ARS registration. If the 
radio’s mobility information and site are known by the MNIS, then the data message is routed to 
the site. If the radio’s mobility information is not known, then the data message is routed to an 
arbitrarily selected site. In both conditions, the data message is transmitted over-the-air to at most, 
two sites. In the following scenario, it is transmitted to only one site: 

• If ARS is enabled for site and system change, or 

• If ARS is enabled for system change, and the radio is still at the site where it has 
registered. 
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If the MNIS is not able to route the message due to a loss of connection with the repeater system, 
or because of any other erroneous condition, then the data message is dropped and an ICMP 
message is returned to the data application. 

4.13.5.5 Group Messages 

Data applications can receive or send group data messages via the MNIS. The MNIS supports 
group list configuration via its configuration GUI. The groups can be specified in a range to allow a 
large number of group affiliations. An example would be groups in the range of 1-100. The data 
messages targeted to the specified groups are sent to the application. The group list can be 
defined based on the type of system configuration: 

• In a conventional system, one group list per slot (1 and 2) can be selected. 

• In a Capacity Plus system, one group list can be selected. 

• In an LCP system, one group list per site can be selected. 

The group list is also used for routing of outbound group messages from the data application. In a 
conventional system, if the target group is present only in the group list of slot 1, then the data 
message is routed to slot 1 only. If the target group is in the group list of slot 1 and slot 2, then the 
data message is routed to both slots. If the slot is configured as an IPSC local channel, then the 
group message is routed to all local channels of that slot. If the group is not in any of the group list, 
then the data message is routed to all the system channels. A group data message is not routed to 
a channel that is configured as a Data Revert Channel. 

In a Capacity Plus system, the group data message is routed to the Rest Channel. In an LCP 
system, if the group is a wide area group as provisioned in the Master repeater, then the data 
message is transmitted at the sites associated with the wide area group. If the group is a local 
group, then the data message is routed and transmitted at the sites where their group list contains 
the target group. If the local group is present in multiple group lists, then it gets transmitted at the 
multiple sites. 

4.13.5.6 Data Privacy 

The MNIS supports both Basic and Enhanced Privacy mechanisms. 

For Basic Privacy, only one key is specified. The specified key is used for descrambling the 
inbound messages that have been scrambled using Basic Privacy. 

The outbound messages can also be scrambled using the specified key if enabled. Outbound 
privacy can be enabled per slot, in a conventional system, or per system in Capacity Plus or LCP. 

The MNIS allows a total of 255 Enhanced Privacy keys to be specified. The inbound encrypted 
messages can be decrypted by any key from the list, which is selected by the MNIS based on the 
key ID value in the inbound message. The outbound messages can be encrypted if enabled. In a 
conventional system, an outbound privacy key can be specified per slot. In an IPSC local slot 
configuration, the selected outbound privacy key applies to all local channels of that slot. In 
Capacity Plus or LCP, one outbound privacy key can be specified per system. 

It is recommended that all radios including the MNIS should have the same privacy settings. If 
Enhanced Privacy is being used, then the MNIS should have the transmit key of all the radios and 
radios should have the outbound key of the MNIS. 
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4.13.5.7 Considerations for Advanced MNIS Configurations 

This section covers in detail a couple of parameters in MNIS configurations. 

In Capacity Plus and LCP configurations, the MNIS has an “Outbound Data Limit” parameter. 
This parameter defines the number of data messages that the MNIS can simultaneously transmit, 
and therefore the maximum number of Trunked Channels that can be busy with data. In LCP 
mode, the parameter can be configured per site. The parameter does not control the number of 
inbound data transmissions from the radio. The configuration ensures that the MNIS does not 
occupy channels more than specified. It does not control system data loading. 4.4 Digital Repeater 
Loading to determine the application data loading that can be supported by the system. 

In an LCP configuration, the MNIS has an “Individual Data to Registered Site” parameter 
which can be enabled or disabled. When enabled, the data message is transmitted only at the site 
where the radio has registered. If the radio roams, then it must re-register at the new site. This 
parameter should be enabled only when all the radios in the system either do not roam, or have 
ARS upon system/site change enabled. The enabling of the parameter has a couple of benefits: 

• The individual data is treated as a local call, and is therefore faster and does not involve 
other sites in a call setup. 

• The call does not engage two sites. 

The enabling of this parameter should be carefully considered, as data delivery could be missed 
when a radio roams, but unable to register immediately after roaming to the new site. 

In conventional configurations, the MNIS has a “Conventional Channel Access” parameter 
that can be set to normal, which is the default setting, or data centric. If the selection is normal, 
then channel access for application data outbound transmissions follow the channel access rules 
similar to what the radios use. The repeater introduces a random delay when the channel is busy. 
The duration of this delay is between 0-1.8 seconds. After this delay, if the channel becomes idle, 
then the data message is transmitted, or another random delay is introduced. This approach is 
used for collision avoidance when the channel is busy with radio activity. If the selection is data 
centric, then the random holdoff is not introduced. The repeater transmits the data immediately 
after the channel becomes free. 

4.13.5.8 DDMS Usage by MNIS 

The DDMS is required by the MNIS, and operation without DDMS is not recommended. 

4.13.5.9 Migrating from Control Station to MNIS 

The control stations can be replaced by the MNIS in systems where the control stations are being 
used for application data communication. In deployments where the control stations are used by 
voice consoles and data applications, it may still be beneficial to replace the control stations and 
monitor data revert channels. For IPSC or LCP systems, the data revert channels can be 
converted to local channels to increase revert data throughput, as control stations are not required 
in the coverage range of the local channel. 

The control stations can be replaced by MNIS without requiring any configuration changes to the 
fielded radios. This is illustrated in the figures below. Figure 4-33 depicts a MOTOTRBO system 
with control stations used by a voice console and data applications. The data applications can be 
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migrated to MNIS-based deployment as shown in Figure 4-34. Since the fielded radios are 
configured with the control station radio ID for the voice console contact and the ARS/TMS 
contact, the MNIS Application ID should be configured with the same ID to avoid configuration 
changes to the fielded radios. This can be accomplished by upgrading the control station to 
firmware versions R02.06.10 or later. Using the CPS, select the “Voice Only” checkbox, which 
configures the radio being used as a control station to ignore data calls received over-the-air. The 
voice console calls continue to be handled through the control station. The data application 
messages are handled through the MNIS. This option is also supported in firmware versions prior 
to R01.11.00. 
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Figure 4-33 System with Control Stations Used by a Voice Console and Data Applications 




Radio ID = 100 
ARS, TMS Radio ID = 1 
Dispatcher Radio ID = 1 



Figure 4-34 System with a Control Stations Used by a Voice Console and MNIS Used by Data Applica- 
tions (Two separate PCs are shown for clarity. The deployments can be on the same PC.) 

NOTE: The MNIS does not support L2 fragmented data. Ensure that the largest data size [Data 
Message + IP/UDP Header] transmitted from the radio is less than the Max TX PDU Size 
configured in the radios. If the largest data sent from the radio is greater than the Max TX 
PDU Size value in the radio, then the value needs to be reconfigured with a larger Max TX 
PDU Size. 
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4.13.5.10 Considerations for the IP Network 

A reliable network is important for application data communication reliability. In the event of a 
network fault, the MNIS could lose connectivity with the entire repeater system, or to some 
selected system sites. The MNIS is designed to automatically establish the link with the repeaters 
after the network is restored. When the MNIS loses connection with a few sites/repeaters, but 
remains connected with other system sites/repeaters, then the MNIS continues to receive and 
route data messages from the connected sites/repeaters. Once the connection is restored, then 
the MNIS automatically resumes receiving and sending data with those sites or repeaters. No user 
intervention is required. The MOTOTRBO RDAC application can monitor the presence of the 
MNIS on the network. 

The MNIS sends/receives a data message as a single datagram whereby the size is dependent on 
the message size, either received or sent, to the data application. 

IP Datagram Size = Max Message Size + Overhead Size (120 bytes) where: 

• Max message size could be the largest message size such as the text message size. 

• Overhead size includes IP/UDP headers, protocol header, authentication, and others. 

• The overhead does not include any VPN-related overhead. 

The bandwidth requirement of the network between the MNIS and the repeater system is not 
large. The bandwidth required is for link establishment with the repeater system, and for receiving 
or sending the data messages to and from the radios. 

The network bandwidth required by the MNIS is due to the Link Management IP traffic between the 
MNIS and the repeaters, and the IP traffic associated with the data messages sent and received 
from the MNIS. The following base values are used when estimating the network bandwidth due to 
MNIS: 

Link Management BW per Repeater Peer = 1 kbps 
Max IP BW due to Data Message per Channel = 7.5 kbps 
% Data Loading on Voice Channel = 40 % 

The sections below covers the formula for estimating the network bandwidth by one MNIS. 

4.13.5.10.1 Estimation of Link Bandwidth Where MNIS is Deployed 

Total Number of Voice Channels in the System = V 
Total Number of Data Revert Channels in the System = D 
Total Number of Repeaters in the System = R 

Downlink BW (IP traffic from repeater system to MNIS): 

• Downlink BW (with Data Revert) = D*7.5 + R*1 kbps 

• Downlink BW (without Data Revert) = V*7. 5*0.4 + R*1 kbps 

Uplink BW (IP traffic from MNIS to repeater system): 



Uplink BW = V*7. 5*0.4 + R*1 kbps 
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4.13.5.10.2 Estimation of Link Bandwidth at Repeater Sites 

If the IP link bandwidth at the site is estimated for voice and data streaming to remote sites, then 
adding bandwidth at the sites is not required. If the IP link bandwidth at the site is not estimated for 
voice streaming as would be the case with single site, IP Site local channel or Capacity Plus 
configurations, then the bandwidth estimate at the site is a follows: 

Total Number of Voice Channels at the Site = v 
Total Number of Data Channels at the Site = d 
Total Number of Repeaters at the Site = r 

Uplink BW (IP traffic from repeater site to MNIS): 

• Uplink BW (with Data Revert) = d*7.5 + r*1 kbps 

• Uplink BW (without Data Revert) = v*7.5*0.4 + r*1 kbps 

Downlink BW (IP traffic from MNIS system to repeater site): 

• Downlink BW = v*7.5*0.4 + r*1 kbps 

There are a few other considerations to take note of: 

• An IPSC wide area channel or a local area channel is considered as one channel. 

• In Capacity Plus: 

Total number of voice channels (V or v) = Number of Trunked Repeaters * 2 

• In LCP: 

Number of Voice Channels (V) = Number of Trunked Repeaters in System * 2 
Number of Voice Channels per Site (v) = Number of Trunked Repeaters per Site * 2 

• The generic formula for MNIS IP bandwidth calculation is: 

BW = BW due to data messages + BW due to Link Management 

• In the case of multiple MNISs, the IP bandwidth due to data messages gets distributed 
between them based on data messages received or sent by them. The IP bandwidth 
due to link management does not get distributed. 

• Additional bandwidth must be budgeted when a VPN is used. 
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4.13.5.10.3 Considerations for Router with Networked Applications 

An application that connects with the repeater system utilizes the Link Management procedure. 
The MNIS and RDAC are examples of applications that connect with the repeater system using 
this procedure. On the contrary, data applications like Location, Text, and others deployed with 
MNIS do not connect with the repeater system. To distinguish between them, an application that 
connects with the repeater system are defined as a networked application. 

The repeaters and the networked applications establish connection with each other in the 
MOTOTRBO system. In certain deployments, however, routers with hair-pinning support are 
required to enable the connection between them. 

The table below provides guidelines when a hair-pinning router is needed. The guidelines are 
generic and not specific to MINIS. 



MOTOTRBO 

System 


Hair-pinning 

Router 


Method of Deployment 


IP Site Connect 


Not Required 


Sites are joined together into the same subnet using 
a VPN. 


Required 


When a VPN is not used and more than one 
networked applications or repeaters are at the same 
subnet, that subnet requires one. 


Capacity Plus 


Not Required 


All the networked applications and the repeaters are 
in the same subnet. 


Required 


When the networked applications are deployed on a 
different subnet, the master site requires one. 

A non-repeater subnet with more than one networked 
applications also requires one. 


Linked Capacity Plus 


Not Required 


All the networked applications and the repeaters are 
in the same subnet as the Master repeater when 
deployed with R02.20.00 LCP hair-pinning 
enhancements. The non-Master repeater sites also 
do not require them. 


Required 


When one or more networked applications are 
deployed at the non-master repeater site. 

A non-repeater subnet with more than one networked 
applications also requires one. 



NOTE: If more than one networked applications are installed on the same PC, then they are 

assumed to be on the same subnet, and require a hair-pinning router to enable connection 
between them. Some routers may not support hair-pinning. If hair-pinning is supported, the 
feature may not be enabled by default. The HP MSR 20-20 supports hair-pinning and is 
suggested for use. 
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4.13.5.11 MNIS and DDMS Computer Specifications 



Component 


Requirements 


Operating Systems 


Windows 7 Home Premium Edition (32 & 64-bit) 


Windows 7 Professional Edition (32 & 64-bit) 


Windows XP Home/Professional Edition with SP3 & Windows Installer 
3.1 (32-bit) 


Windows Server 2003 (32 & 64-bit) 


Windows Server 2008 R2 (64-bit) 


Memory 


MNIS and DDMS: 1 GB and above required by host Operation System 


Hard Disk 


MNIS and DDMS Programmer Install: 5 GB (Program Files & Database) 


Software 


Running multiple instances of MNIS and DDMS are not supported. 
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4.14 CSBK Data System Design Considerations 

When configuring the CSBK data feature in a system, keep in mind the following items: 

• CSBK data does not support Basic Privacy, Enhanced Privacy, or any foreseeable 
privacy features. 

• CSBK data does not support confirmed data delivery mode even if the data call 
confirmed is configured by CPS. 

• The CSBK data can only be routed to the PC via USB connection. 

• The ARS and LRRP protocols are enhanced to support CSBK data. Therefore legacy 
LRRP and ARS application server cannot work with the CSBK data feature enabled. 

• The location information is compressed into a single CSBK, and recovered at the control 
station or MNIS with the location information of the repeater. IPSC/LCP does not work 
with a control station for location CSBK data, because the control station does not know 
where the location data comes from. However, IPSC/LCP works with the MNIS. 

• When cadence 7.5 seconds and 15 seconds are expected, the feature should be 
enabled and window size set to one or two. Take note that a one-time window will not be 
requested to send the GPS data missed periodic window when the cadence is 7.5 
seconds or 15 seconds. This means location updates will not get queued during voice 
calls. Therefore the update success rate gets impacted when the voice loading is high. 

• The XCMP device to server raw data must not exceed 7 bytes, otherwise the error 
indication gets broadcasted to the XCMP device. 

• The following is a list of limitations for GPS report: 

• The distance between the radio and the repeater (receiving inbound GPS data 
over the air) must not exceed 130 miles (approximately 209 kilometers). 

• Latitude system error horizontal distance of less than 8 feet (approximately 
2.4 meters) is introduced. 

• Longitude system error horizontal distance of less than 6 feet (approximately 
1.8 meters) is introduced. 

• Speed-horizontal of 1 knot accuracy, maximum 1 38 miles (approximately 222 
kilometers) per hour, is supported by an Enhanced GPS channel when GPIO 
pin status change is not required. 

• Direction-horizontal of 16 cardinal directions, is supported by an Enhanced 
GPS channel when GPIO pin status change is not required. 

• Info-Time of minutes and seconds, therefore suggested required maximum 
info age shall not exceed 50 minutes, is supported by an Enhanced GPS 
channel. 

All radios, repeaters, MNIS, ARS and LRRP applications enabled with the CSBK data feature will 
keep backward compatibility with radios prior to R02.30.00. In order to ease migration, ARS will be 
transmitted as CSBK data when the feature is enabled via CPS per channel. The LRRP server will 
know if the radios have the capability to transmit the LRRP report as CSBK data through the ARS 
registration. The LRRP report cannot be transmitted as CSBK data when the channel is not 
enabled with CSBK data feature. Therefore, if the ARS message does not indicate CSBK data 
capability, the LRRP server should not send the LRRP request to demand the radio to transmit 
LRRP report as CSBK data. If such LRRP requests are sent before, the LRRP stop should be sent 
to the radio to cancel the request. There are a few considerations to take note of: 
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• ARS: When the feature is enabled by CPS, the radio sends the ARS registration as 
CSBK, the control station and MNIS sends the ARS registration to the ARS server with 
optional payload 0x10 0x80 when the ARS CSBK data is received. 

• ARS: When the ARS server (DDMS) sends the Device Registration ACK with optional 
payload 0x10 0x80, the control station and MNIS sends the ACK as CSBK data. 

• LRRP: When the CSBK data feature is enabled at a channel via CPS and the location 
request contains a LRRP token for CSBK location feature (0x40, 0x01, 0x41), the LRRP 
(GPS) message with location data is sent as CSBK. 

• LRRP: When the CSBK data feature is enabled at a channel via CPS, the LRRP (GPS) 
message without location data (such as LRRP triggered answer) will be sent as CSBK. 
If the message cannot be carried in one single CSBK, it will be sent as a DMR data 
packet. 
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4.15 GPIO Triggered Event Driven and Distance Driven 
Location Update System Design Considerations 

When configuring the GPIO Triggered Event Driven and Distance Driven Location Update in a 
system, the rules listed below need to be followed: 

• To support GPIO Triggered Event Driven Location Update, 

1 For portable, the Cable Type should be configured as Generic or Telemetry or 
Motorola Solutions if the cable is a smart Telemetry cable; 

2 For both portable and mobile, the Feature of GPIO Physical Pins should be 
configured as Generic Input or Telemetry VIO, and if Telemetry VIO is 
configured, the Action of such VIO should be configured as output command 
because output command indicates the GPIO as an input pin. 

• For Distance Driven Location Update, to avoid triggering the update too often, it is 
recommended to configure the distance to be 100 meters or larger. 

• For GPIO triggered event driven update, the location report cannot be guaranteed if two 
events are triggered within 200ms. 

• The GPIO Triggered Event Driven and Distance Driven Location Update will not be sent 
periodically like the interval triggered GPS update; therefore, the reliability may be a 
concern and needs to be addressed. Some reliability considerations are as follows: 

1 Don’t configure the gap between the updating distances to be too large. If the 
gap between the updating distances is reasonable, even if some location 
updates are missed over the air, the location tracking can still have enough 
updates; 

2 At the same time, keep a periodic location update with a long interval, so that 
the subscriber will not be out of track when it’s not moving or moving slowly; 

3 At Non-EGPS Channel, use confirmed GPS update. Please note that 
confirmed data delivery can increase the reliability, but it will also increase the 
time away from the home channel at the same time; 
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4.16 Customer Fleetmap Development 

In a MOTOTRBO system, the system administrator can maximize the system's communication 
effectiveness by translating their organization's operation requirements into a list of supported 
features. The result of identifying and formalizing this information is often referred to as 
fleetmapping. 

Fleetmapping can be thought of as: 

• Assigning groups to the radios issued to personnel. 

• Assigning groups to the dispatcher control positions. 

• Assigning groups to channels and slots. 

• Defining the feature subsets available to the personnel using the radios and dispatcher 
control positions. 

A fleetmap determines how the radio communications for each user group of an organization is 
controlled. Through controlling communications between different user groups and between 
individuals within a group, the organization can manage the radio communications system 
resources efficiently. Fleetmapping also provides a structured approach to the management of a 
large number of radio users, and provides the opportunity to plan in advance for expansion or 
changes within an organization. 

Some of the factors that should be considered when creating or planning changes to the fleetmap 
are: 

• Identifying a functional fleetmap design team 

• Identifying radio users 

• Organizing radio users into groups 

• Assigning IDs and aliases 

• Determining feature assignments: 

• Private Calls 

• All Call 

• PTT ID and Aliasing 

• Radio Disable 

• Remote Monitor 

• Radio Check 

• Call Alert 

• Emergency Configurations 

• Determining channel access requirements 

• Determining subscriber programming requirements 

• Determining data application access and requirements 

4.16.1 Identifying a Functional Fleetmap Design Team 

To develop a fleetmap, a design team of key representatives from the customer’s system 
managers, technicians, and operators needs to be formed to create effective communications 
plans for radio users and system operators. 
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4.16.2 Identifying Radio Users 

The system administrator needs to do the following to establish a fleetmap. 

• Determine the customer’s organizational structure from a radio user’s perspective 

• Consider the needs of portable and mobile radio users 

• List all of the potential radio users in a single column on a spreadsheet 

• Define the functional groups that use the system 

• Group together radio users who need to communicate with each other on a regular 
basis 

Typically, each functional group of radios will have different communication requirements. 
Therefore, each functional group will have their own codeplug for their radios that differs from 
other functional groups. 



Codeplug 


Functional 

Group 


User 

Name 


Alias 


User 

ID 


Talks with 


Listens 
only to 


construction. ctb 


Construction 


John 


John 


1873 


Construction, 

Transport 


Security 


Construction 


Bob 


Bob 


1835 


Construction, 

Transport 


Security 


Construction 


Rick 


Rick 


542 


Construction, 

Transport 


Security 


security.ctb 


Security 


Al 


Al 


98 


Security, 

Administrative 


- 


Security 


Joe 


Joe 


4762 


Security, 

Administrative 


- 


administrative. ctb 


Administrative 


Frank 


Frank 


6654 


Administrative, 

Security 


- 


Administrative 


Mike 


Mike 


19172 


Administrative, 

Security 


- 


Administrative 


Steve 


Steve 


78378 


Administrative, 

Security 


- 


transport.ctb 


Transport 


Lenny 


Lenny 


23 


Transport, 

Construction 


Security 


Transport 


Carl 


Carl 


2 


Transport, 

Construction 


Security 
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4.16.3 Organizing Radio Users into Groups 

Once you have identified all of the individual users, associate them with groups. The 
communication requirements for one group may differ with the requirements of another group. 
Certain groups may need to communicate with multiple groups, in addition to their primary group. 
Therefore, you will need to identify the individual radios and the corresponding groups that they 
need to communicate with. Also note that the group organization may be different from the 
organization’s formal reporting structure. 

You will also need to determine the traffic patterns of the individual users and functional groups, so 
that channel, slot and group assignments can be associated with each user. “Digital Repeater 
Loading” on page 284 should provide information to help decide the distribution of groups, logical 
channel assignments (slots) and physical channel assignments. 

When organizing your MOTOTRBO system, remember that individual users, radios, and groups all 
have different requirements. Subsequently, they also have different parameters associated with 
them. Organize the radios, groups and slot assignments in a spreadsheet. An example is shown 
below. 





Functional group and talkgroup mapping 


Construction 


Security 


Administrative 


Transport 


TG ID: 62 


TG ID: 54 


TG ID: 46 


TG ID: 8766 


TG ID: 123 


TG ID: 99 


TG ID: 997 


TG ID: 368 


Cement factory 


Metal shop 


Carpenters 


Patrol 


Front desk 


Admin 


Delivery trucks 


Cement mixers 


ch 1 - slot 1 


ch 2 - slot 1 


ch 2 - slot 1 


ch 2 - slot 1 


ch 1 - slot 1 


ch 2 - slot 1 


ch 1 - slot 1 


ch 2 - slot 1 


File codeplug as 


Functional group 


User name 


Alias 


User ID 


Talks with functional 
groups 


Listens only to 
functional groups 


















construction. ctb 


Construction 


John 


John 


1873 


Construction, 

Transport 


Security 


X 














X 


Construction 


Bob 


Bob 


1835 


Construction, 

Transport 


Security 






X 








X 




Construction 


Rick 


Rick 


542 


Construction, 

Transport 


Security 


X 


X 


X 










X 


security.ctb 


Security 


Al 


Al 


98 


Security, 

Administrative 










X 


X 


X 






Security 


Joe 


Joe 


4762 


Security, 

Administrative 










X 


X 


X 






administrative.ctb 


Administrative 


Frank 


Frank 


6654 


Administrative, 

Security 












X 


X 






Administrative 


Mike 


Mike 


19172 


Administrative, 

Security 












X 


X 






Administrative 


Steve 


Steve 


78378 


Administrative, 

Security 










X 


X 


X 






transport.ctb 


Transport 


Kenny 


Kenny 


23 


Transport, 

Construction 


Security 




X 


- 








X 


X 


Transport 


Carl 


Carl 


2 


Transport, 

Construction 


Security 


X 
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4.16.3.1 Configuration of Groups 

In MOTOTRBO systems, capabilities for Group Calls are configured via the subscriber (portable 
and mobile) CPS. The repeater does not require any specific configuration with respect to groups. 
There are three interrelated steps in configuring your radios to participate in Group Calls; it is 
configured through the “Contacts”, “RX Group Lists” and “Channels” menu folders in CPS. While 
the MOTOTRBO CPS enables great flexibility in configuring your system for Group Calling, one 
basic procedure is as follows: 

1. In the “Contacts” folder, go to the “Digital” folder, and add a call of type “Group Call.” The CPS 
will provide a default name and ID; you will need to assign a unique ID between 1 and 
16776415, and should also rename the Group Call to an intuitive alphanumeric name 
representative of the user workgroup that will ultimately be using this group, e.g. 
“Maintenance.” All Calls created in the “Contacts” folder appear in the “Contacts” menu of the 
subscriber by name, and the Group name also appears on the radio display when a Group 
Call is received. In step 3 below, you will assign this Group Call, again by name, to the 
Transmit (TX) “Contact Name” attribute of a channel. 

2. In the “RX Group Lists” folder, add a new group list, and then add the Group Call you just 
created to be a member of the list. The group list controls which groups a radio will hear 
when tuned to a selected channel. For example, if members of the Maintenance group 
should also be able to listen to other groups on the channel, those other groups would be 
added to the RX Group List; if members of the Maintenance group should only hear traffic 
related to their own group, then only the Maintenance group would be added to the group 
list. The group list should again be renamed to something intuitive; in step 3 below you will 
assign this group list, by name, to the RX Group List attribute of a channel. 

3. In the channels menu, each “zone” can contain up to 16 channels that can be mapped to 
the 16-position top selector knob of the portable radio or the relative channel number 
selections on a mobile. Radio users that require more than 16 channels must organize 
them into multiple folders in CPS, so that they can be accessed as “zones” in the radio 
menu. Zones, if used, can and should also be given names. In an appropriate folder, 
create a new digital channel. To fully define the channel, you must assign the appropriate 
receive and transmit frequencies, and also select the TDMA slot number. Then, add the 
group list you defined in step 2 above to the RX Group List attribute, followed by adding 
the digital Group Call to the TX Contact Name attribute. You will also need to define the TX 
Admit Criteria. Rename the channel to something intuitive, and assign it to a knob 
position; the channel name will be displayed on the radio whenever it is selected via the 
top knob on a portable or the up/down channel selection buttons on a mobile. 

If configured as described above, radio users are able to place a Group Call simply by selecting 
the defined channel and pressing PTT. Groups can also be selected from the Contacts menu on 
display radios, as enabled by step one of the above. It is also possible to assign a Group Call to a 
radio programmable button (called a “one touch call” in CPS) so that users can place a Group Call 
at the touch of a button. 

4.16.4 Assigning IDs and Aliases 

Each radio, group, and control station in the system must have a unique ID number and alias. 
There should be no duplicate IDs on the system. 
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4.16.4.1 Identifying Radio IDs 

Radio IDs for a MOTOTRBO system range between 1 and 16776415. There are two approaches 
to identifying radio IDs: 

Option A: 

As a general practice, create contiguous ID ranges, but allow room for future expansion. As an 
example, a department has a current requirement for 1200 IDs. However, the department may 
need up to 2000 IDs in 12 months. Assigning the IDs during planning saves future re-programming 
of radios and subscriber records. 

Option B: 

The radio ID can be created so that each ID will provide certain information about the radio. Each 
digit in the Radio ID can represent a certain code or radio type. For example: 



16776415 



► Range 0-9999. Sequence Number 

► Range 0-6. 0 - Reserved 

1- MOTOTRBO Portable 

2 - MOTOTRBO Mobile 

3 - Analog Portable 

4 - Analog Mobile 

5 - Reserved 



Other options are to use a digit to identify the user’s home group or other identifier. Radio IDs are 
not centrally maintained or managed in a MOTOTRBO system. It is up to the system administrator 
to document the radio ID designation. Note that these IDs must match those entered in other 
radios and data applications in order for the system to operate correctly. 

4.16.4.2 Assigning Radio Aliases 

You can assign an alias to each radio user. Although anything can be used as an alias, the user’s 
last name is often used. Radios that are assigned to vehicles are often aliased with the vehicle 
number such as “Cab 35” or “Fire Truck 3.” If radios are used by multiple users through different 
shifts, the job description is often used such as “West Side Guard” or “Cleaning Crew 2.” Since 
unique names are required, no two radio users should have the same alias. Aliases should be 
consistent in all radio programming (CPS), and the data applications. Databases are not shared 
between the various applications. There is no centralized database in MOTOTRBO. Since aliasing 
is done independently on each device, if the alias and ID do not match in each device in the 
system, customers may become confused. 
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An example of a spreadsheet showing a possible radio ID and alias database is shown below: 



Functional 

Group 


User 

Name 


Alias 


Unit ID 


Talks with 


Listens 
only to 


Construction 


John 


John 


1873 


Construction, Transport 


Security 


Construction 


Bob 


Bob 


1835 


Construction, Transport 


Security 


Construction 


Rick 


Rick 


542 


Construction, Transport 


Security 


Security 


Al 


Al 


98 


Security, Administrative 


- 


Security 


Joe 


Joe 


4762 


Security, Administrative 


- 


Administrative 


Frank 


Frank 


6654 


Administrative, Security 


- 


Administrative 


Mike 


Mike 


19172 


Administrative, Security 


- 


Administrative 


Steve 


Steve 


78378 


Administrative, Security 


- 


Transport 


Lenny 


Lenny 


23 


Transport, Construction 


Security 


Transport 


Carl 


Carl 


2 


Transport, Construction 


Security 



4.16.4.3 Identifying Group IDs 



Group IDs for a MOTOTRBO system range between 1 and 16776415. The same approach that is 
used to identify radio IDs can be used for Group IDs. Group IDs are not centrally maintained or 
managed in a MOTOTRBO system. It is up to the system administrator to document the Group 
designation. Note that these IDs must match those entered in other radios and data applications in 
order for the system to operate correctly. 

4.16.4.4 Assigning Group Aliases 

The groups should also be consistent throughout the system. Display radios and data applications 
identify groups by alias. Groups should be named with an alias the customer will easily 
understand. Highly abstract names often cause confusion. When assigning aliases, you will need 
to consider character and subscriber limitations. Some radio models may allow more or fewer 
characters than the data applications. Since aliasing is done independently in each device, if the 
alias and ID do not match in each device in the system, customers may become confused. An 
example is shown below: 



Functional group and talkgroup mapping 
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Administrative 


Transport 


TG ID: 62 


TG ID: 54 


TG ID: 46 


TG ID: 8766 


TG ID: 123 


TG ID: 99 


TG ID: 997 
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0 

Q_ 
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2 

0 

CL 
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desk 


E 

T3 

< 


> ^ 
11 


E 0 

0 

O E 


ch 1 - slot 1 


ch 2 - slot 1 


ch 2 - slot 1 


ch 2 - slot 1 


ch 1 - slot 1 


ch 2 - slot 1 


ch 1 - slot 1 


ch 2 - slot 1 
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4.16.5 Determining Which Channel Operates in Repeater Mode or 
Direct Mode/Dual Capacity Direct Mode 

Repeater mode enables unit-to-unit communications using the repeater. Direct mode/dual 
capacity direct mode enables unit-to-unit communications without using the repeater. Each 
channel on the radio is programmed to be either a direct mode channel, dual capacity direct mode 
or a repeater mode channel via the CPS. 

Channels defined as Repeater channels in the CPS can be toggled to operate in Talkaround mode 
via user selection from the menu or a programmable button. When this happens, the transmit 
frequency is set equal to the receive frequency, and this channel effectively performs like a Direct 
Mode channel. 

If a 12.5 kHz RF channel is used for dual capacity direct mode, both timeslots are provisioned for 
6.25e direct mode only. Similar to repeater mode, 6.25e channels are configured via CPS to 
operate in either timeslot 1 or timeslot 2, and color code (0-14) can be provisioned differently in 
each timeslot. The full range of radio IDs and talkgroup IDs are available for use in 6.25e direct 
mode (dual capacity direct mode). 

4.16.6 Determining Feature Assignments 

4.16.6.1 Determining Supervisor Radios 

Supervisor radios are not defined in the CPS by any specific “Supervisor” option. Instead they are 
subscribers that have supervisory options enabled. Supervisor radios are responsible for 
acknowledging Emergency Calls and alarms, and also perform administrative duties such as 
remote monitor and selective radio inhibit. Some features should only be allowed to users that can 
use them responsibly. 

4.16.6.2 Private Calls 

In MOTOTRBO systems, capabilities for Private Calls are configured via the subscriber (portable 
and mobile) CPS. The repeater does not require any specific configuration with respect to Private 
Calls. While the MOTOTRBO CPS enables great flexibility in configuring your system for Private 
Calling, one basic procedure is as follows: 

1. Every MOTOTRBO radio in a system should be assigned a unique radio ID in the CPS. This 
parameter is programmed in the Radio ID field under the General Settings menu. 

2. In the “Contacts” folder, go to the “Digital” folder, and add a call of type “Private Call.” The 
CPS will provide a default name and ID; assign the actual radio ID of the radio that is to be 
privately called to this field, and rename the call to an intuitive alphanumeric name 
(representative of the radio that to be addressed). Note that All Calls created in the 
“Contacts” folder appear in the “Contacts” menu of the subscriber by name, and this name 
also appears on the radio display when a Private Call is received. 

If configured as above, radio users are able to make Private Calls by selecting the Private Call, by 
name, from the radio’s Contacts menu. In addition, similar to assigning a Group Call to a channel 
as described above, it is also possible to assign a Private Call to the TX Contact Name attribute of 
a channel, so that users can place Private Calls by making the appropriate channel selection via 
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the top knob on a portable or up/down channel select buttons on a mobile. It is also possible to 
assign a Private Call to a radio programmable button (called a “one touch call” in CPS) so that 
users can place a Private Call at the touch of a button. These latter 2 methods are the only 
methods for non-display radios to place Private Calls. 

Please note that a radio can, in practice, receive a Private Call from any other radio that is 
available on the channel, regardless of whether the receiving radio has created a CPS Private Call 
entry for that radio. The receiving radio will in this case display the radio ID of the calling radio, 
rather than an alphanumeric alias. Similarly, a radio can place a Private Call to any other radio by 
utilizing the “manual dialing” option in the radio’s menu, however in this case the user must know 
the Radio ID of the called party. 

4.16.6.3 All Call 

In MOTOTRBO systems, capabilities for All Calls are configured via the subscriber (portable and 
mobile) CPS. The repeater does not require any specific configuration with respect to All Calls. 
While the MOTOTRBO CPS enables great flexibility in configuring a system for All Calls, one basic 
procedure is as follows: 

1 . In the “Contacts” folder, go to the “Digital” folder, and add a call of type “All Call.” The CPS will 
provide a default name; rename the call to an intuitive alphanumeric name representative of 
the All Call. All Calls created in the “Contacts” folder appear in the “Contacts” menu of the 
subscriber by name. 

If configured as above, a user would initiate an All Call by selecting the call, by name, from the 
radio’s Contacts menu. Additionally, similar to assigning a Group Call to a channel as described 
above, it is possible to assign an All Call to the TX Contact Name attribute of a channel, so that 
users can place All Calls by making the appropriate channel selection via the top knob on a 
portable or up/down channel select buttons on a mobile. This is the only method for a non-display 
radio to place an All Call. 

It is also possible to assign an All Call to a radio programmable button (called a “Number Key 
Quick Contact Access” in the CPS), so that users can place an All Call at the touch of a button. 
However, this method to initiate an All Call, is only supported on the display portable radios and via 
a keypad microphone with the alphanumeric display mobiles. 

Since All Calls are monitored by everyone on a slot, it is suggested that only supervisors be 
granted the ability to transmit All Calls. 

4.16.6.4 Radio Disable 

In MOTOTRBO systems, Radio Disable is configured in the portable and mobile radio CPS. To 
allow a radio the ability to initiate this function, this option must be enabled in the CPS “Menu” 
settings. To permit (or prevent) a given radio from decoding and responding to this command, this 
option must be configured in the CPS “signaling systems” settings. 

Since the ability to disable a user could be misused, it is suggested that only supervisors be 
granted the ability to initiate a Radio Disable. 
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4.16.6.5 Remote Monitor 

In MOTOTRBO systems, Remote Monitor is configured in the portable and mobile radio CPS. To 
allow a radio the ability to initiate this function, this option must be enabled in the CPS “Menu” 
settings. To permit (or prevent) a given radio from decoding and responding to this command, this 
option must be configured in the CPS “signaling systems” settings. If a radio is configured to 
decode the remote monitor command, the duration that the target radio will transmit after receiving 
a Remote Monitor command can be set in the CPS “signaling systems” settings of the target radio. 

Since the ability to remotely monitor a user could be misused, it is suggested that only supervisors 
be granted the ability to initiate a Remote Monitor. 

4.16.6.6 Radio Check 

In MOTOTRBO systems, Radio Check is configured in the portable and mobile radio CPS. To 
allow a radio the ability to initiate this function, this option must be enabled in the CPS “Menu” 
settings. All MOTOTRBO radios decode and respond to a Radio Check. 

4.16.6.7 Call Alert 

In MOTOTRBO systems, Call Alert is configured in the portable and mobile radio CPS. To allow a 
radio the ability to initiate this function, this option must be enabled in the CPS “Menu” settings. All 
MOTOTRBO radios decode and respond to a Call Alert. 

4.16.6.8 RX Only 

In MOTOTRBO, a radio can be configured as a receive only (RX Only) device and does not 
transmit. The RX Only mode of operation is useful when a radio user monitors the radio 
communication, or in hospitals where RF transmission is harmful. 

In Capacity Plus, Revert Control Stations should be configured as “RX Only” radios, only if the data 
messages are transported over-the-air as unconfirmed data messages. For confirmed data 
messages, a RX Only Revert Control Station will not send acknowledgement and a radio will send 
the same data message multiple times. Multiple transmissions waste the air bandwidth and cause 
the server to receive duplicate messages. 

4.16.6.9 Remote Voice Dekey 

In MOTOTRBO systems, Remote Voice Dekey is configured in the portable and mobile radio CPS. 
If used in a repeater system, the repeater does not require any specific configuration with respect 
to Remote Voice Dekey. However, the repeater needs to be using Transmit Interrupt capable 
software. To allow a radio the ability to initiate this function, this option must be enabled via the 
CPS. Only MOTOTRBO radios provisioned with the ability to be interrupted dekeys in response to 
the Remote Voice Dekey command. 

The Remote Voice Dekey feature can be used in direct, talkaround, or repeater modes of 
operation. 

The Remote Voice Dekey feature is capable of remotely dekeying group voice calls and private 
voice calls; Emergency Calls and non-Emergency Calls; and can be used regardless of whether 
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the initiating radio is a member of the call being remotely dekeyed. Since it is possible for this 
feature to remotely dekey a call that the radio is not unmuted to, the radio user may not be aware 
of the nature of the call that is being remotely dekeyed. Accordingly, it is recommended that this 
feature be enabled only in supervisor radios and the radio users be trained on the proper use of 
the Remote Voice Dekey feature. 

The Remote Voice Dekey feature is not capable of remotely dekeying All Calls or non-voice (i.e., 
data or control) calls. 

4.16.7 Emergency Handling Configuration 

Configuring a communication system (like MOTOTRBO) to handle emergency situations requires 
some up front design. In emergency situations, it is ideal that when a user initiates an emergency, 
he is immediately routed to someone who can handle his emergency situation. The previous 
sections have addressed some basic feature descriptions of how emergency can operate. This 
section will outline in detail how to program the numerous devices in the system in order to meet 
the needs of a customer’s emergency needs and also provide some guidance on choosing the 
available options. It is recommended to review the Emergency Handling feature explanation in the 
earlier chapters. 

It is important when creating an emergency handling plan to understand the customer’s existing 
emergency procedures. An interview with a representative in charge of emergency operations is 
usually required to fully understand the process. This information will act as a base for selecting a 
configuration. 

4.16.7.1 Emergency Handling User Roles 

The first step is identifying users that will participate in the emergency handling plan. There are 
three major roles to identify: Emergency Initiator, Monitoring Supervisor, and Acknowledging 
Supervisor. 

An Emergency Initiator is a user that does not necessarily have any responsibility for handling 
emergencies, but is expected, at some point to have an emergency that needs handling. This 
user’s radio is configured with either an emergency button or an external switch to initiate an 
emergency. The radio needs to be programmed on how to contact a Supervisor based on the 
selected configuration. Alternatively, this radio can be programmed to give a non-persistent 
indication (display and/or audio) that the current call is an Emergency Call. This indicates to the 
user that he should avoid interfering with the call taking place. The majority of users in a system 
will be considered Emergency Initiators. 

A Monitoring Supervisor is a user that needs to know when an emergency occurs, but is not the 
individual identified to handle and acknowledge emergencies. This user’s radio will provide an 
indication that an Emergency Alarm has been received and provide an indication that an 
Emergency Call is taking place. This user does not transmit an acknowledgement to the 
Emergency Alarm. The Emergency Alarm will be persistent on the Monitoring Supervisor’s radio 
until manually cleared. Duplicate attempts of the same Emergency Alarm will not restart the 
Emergency indication. There can be multiple Monitoring Supervisors per group. A Monitoring 
Supervisor may also be an Emergency Initiator. 

An Acknowledging Supervisor is the user specifically identified to respond to received emergency 
situations. This user’s radio provides an indication that an Emergency Alarm has been received, 
and provides an indication that an Emergency Call is taking place. In addition to the indications, 
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this user’s radio is responsible for transmitting an acknowledgement to the Emergency Initiator. 
Until the Emergency Initiator receives the acknowledgement, his radio will continue to transmit its 
emergency alarm messages, until his user takes action to stop or the radio exhausts the number of 
programmed retries. It is important to note that the Acknowledging Supervisor’s radio (not the 
user) sends the acknowledgement, when it receives the Emergency Alarm. Reception of an 
emergency alarm acknowledgement only guarantees that the radio received the message, not the 
user. Because it is the responsibility of the Acknowledging Supervisor to stop the Emergency 
Initiator’s retries, duplicate attempts of the same Emergency Alarm will restart the emergency 
indication if cleared. It is highly recommended that there only be one Acknowledging Supervisor 
per group and slot. If there is more than one, acknowledgement messages may interfere with each 
other when transmitting, and cause a delay in acknowledging the Emergency Initiator. An 
Acknowledging Supervisor may also be an Emergency Initiator. 

These MOTOTRBO radios are configured to operate in each role by setting a few options using 
the CPS, as described in the following table. Note that these options are configurable per channel, 
and therefore per Group, Frequency and Slot. This means that a user can play a different role 
depending on the channel he has selected. He may be an Acknowledging Supervisor for one 
Group, but only an Emergency Initiator on another. Note that the selected Digital System 
references a group of parameters used, when a user initiates an emergency. A radio programmed 
with a Digital Emergency System of None will not be able to initiate an emergency on that channel. 
The parameters contained within the digital system will be discussed in detail later. 





CPS Option per Channel 


Emergency 
Handling Role 


Digital 

Emergency 

System 


Emergency 

Alarm 

Indication 


Emergency 
Alarm Ack 


Emergency 

Call 

Indication 


Emergency Initiator 


Selected 


Disabled 


Disabled 


Optionally 

Enabled 


Monitoring Supervisor 


Selected Or 
None 


Enabled 


Disabled 


Enabled 


Acknowledging 

Supervisor 


Selected Or 
None 


Enabled 


Enabled 


Enabled 



By identifying the roles in the customer’s organization, it should start to become clear how they 
handle emergencies at a high level. If there are numerous supervisors, it is important to note which 
groups these supervisors monitor, as there may be more than one supervisor that monitors 
multiple or all the groups. This will be the key to deciding on an emergency handling strategy. 

4.16.7.2 Emergency Handling Strategies 

There are two major strategies to handle emergency situations: Tactical or Centralized. 

A Tactical emergency handling strategy is when the Emergency Initiators transmit their emergency 
alarm and call on the channel, group and slot they are currently selected on. This assumes that 
there is an Acknowledging Supervisor that is monitoring that same channel, group or slot. This 
means that each group is required to have a designated supervisor whose responsibility is to 
handle emergency situations. Because emergency alarms do not traverse slots or channels, there 
would need to be one (and only one) supervisor designated for each group on every channel and 
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slot. Multiple Monitoring Supervisors could be configured to monitor for emergency alarms without 
sending acknowledgements to stop the Emergency Initiator’s retries. It is also very important to 
note that because users are generally mobile it is possible that the Acknowledging Supervisor 
becomes unavailable, busy, changes channels, or roams out of range of the system. If this 
happens, Emergency Initiators may go unacknowledged. 

In a system with a small number of users and groups, a Tactical strategy is often the easiest 
method to implement. When the number of users, groups, and channels grow, the required 
number of Acknowledging Supervisor also grows. It will quickly become difficult to guarantee the 
multiple assigned Acknowledging Supervisors are actively monitoring their assigned groups. It is 
also often not cost effective to have numerous designated Acknowledging Supervisors handling 
emergency situations. 

In order to operate Tactically, the Emergency Initiator needs to be on a channel that is configured 
with a Digital Emergency System, and has its Emergency Revert Channel set to “Selected” in the 
CPS. Since this is set on a per channel basis, a radio could be configured to operate differently 
based on the selected channel. 

A Centralized emergency strategy is when the Emergency Initiators transmit their emergency 
alarm and call on a dedicated channel, group or slot. This strategy is often referred to as a “revert” 
strategy. This strategy assumes that there is one dedicated Acknowledging Supervisor whose job 
is to handle the emergencies of all users in the system, and that the Emergency Initiators 
automatically change or “revert” to the channel the Acknowledging Supervisor is operating on to 
process their emergency. Because this Acknowledging Supervisor’s role is only to monitor for 
emergencies, it becomes easier to manage his availability. Further steps can be taken to 
guarantee the availability of the Acknowledging Supervisor. It is a good idea to locate the 
Acknowledging Supervisor’s radio in a good RF coverage area of the system, so not to go out of 
range. Having a designated RF channel and slot that is specifically used for managing 
emergencies, lowers the possibility of encountering a busy system when there is heavy 
emergency traffic. 

In larger systems the Acknowledging Supervisor’s role in a centralized configuration is often 
referred to a Dispatcher. It is not expected that this Acknowledging Supervisor will leave his 
location and actually resolve the emergency himself. His role is to contact and dispatch other 
resources to handle the emergency that was reported. The Acknowledging Supervisor is able to 
switch channels to dispatch assistance to the Emergency Initiator, and then switch back to the 
emergency channel. 

In some cases multiple Centralized configurations may be required. This is often needed when the 
number of users becomes too much for one Acknowledging Supervisor to handle, or if the 
customer’s organization is broken into multiple organizations that have their own Acknowledging 
Supervisor. This may also be required if a system contains multiple repeaters with non-overlapping 
RF coverage. While operating on one site, a radio may not be in range of another site, therefore if 
he were to revert to the other site to process an emergency, he may not be in the coverage range 
of the repeater to complete the transmission. In this scenario, it is recommended that an 
Acknowledging Supervisor be designated for each RF coverage range. This would require a radio 
be configured to revert to channels within RF coverage of the selected channel. 

In order to revert to a Centralized channel, the Emergency Initiator needs to select the channel 
that is configured with a Digital Emergency System, and has its Emergency Revert Channel set to 
the designated Emergency Channel in the CPS. Since this is configured on a per channel basis, a 
radio could be configured to operate differently based on the selected channel. There are 32 
Digital Emergency Systems available. This means that one radio can be configured to revert to 32 
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different channels, depending on the configuration of the Digital Emergency System that is 
assigned to the selected channel. 

It is not recommended that a Centralized emergency strategy be implemented using Emergency 
Initiators operating Tactically and one Acknowledging Supervisor scanning multiple channels. 
When multiple emergencies occur simultaneously it is more effective for the Emergency Initiators 
to come to the Acknowledging Supervisor rather the Acknowledging Supervisor searching for the 
Emergency Initiators. 

4.16.7.3 Acknowledging Supervisors in Emergency 

The emergency strategy of the Acknowledging Supervisor himself should be considered. Since 
this user is the one identified to handle emergencies, who should he attempt to contact if he has 
an emergency. In a tactical environment, the user may only need to change or possible “revert” to 
another channel to contact another Acknowledging Supervisor. In a centralized configuration with 
multiple dispatchers, one Acknowledging Supervisor dispatcher could be configured to revert to 
the other Acknowledging Supervisor dispatcher. If there is no other individual to contact, the 
Acknowledging Supervisor may simply wish to operate tactically, and transmit his emergency on 
the selected channel so that the Monitoring Supervisors can be contacted. 

4.16.7.4 Extended Emergency Call Hang Time 

As previously described, the MOTOTRBO repeater reserves the channel for a short duration after 
a voice transmission. By default the call hang time associated with an emergency is slightly larger 
than those for Group Calls and Private Calls. The repeater can be configured to extend the call 
hang time for Emergency Calls even longer to provide an additional opportunity for the Emergency 
Initiator or Emergency Acknowledger to communicate without competing with other users. 

4.16.7.5 Emergency Revert and GPS/Data Revert Considerations 

During registration with the Location Server the radio receives a periodic location update request 
and an emergency location update request. When the radio enters the emergency state it will 
attempt to transmit the emergency location update response on a specific channel. The 
transmission channel of this message is defined by the radio’s Emergency Mode (Emergency 
Alarm, Emergency Alarm with Call or Emergency Alarm with Voice to Follow) and its GPS 
Transmission Channel (Selected or Revert). Understanding which channel is used for the 
Emergency Location Update is important, as a control station is required on that channel to enable 
the reception of the message by the Application Server. For more information on emergency 
handling, see See “Emergency Handling Strategies” on page 410. 
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The following sections define how Emergency Revert and GPS Revert interact when the 
Emergency Revert Channel contains a GPS Revert Channel and the radio received a Emergency 
Location Update Request on the Selected Channel. These are sample scenarios intended to aid in 
understanding the interactions. The following sections use a direct mode configuration to simplify 
the diagrams, though they can also be applied to repeater mode. The radio initiating the 
emergency has been configured with the following channels; GROUP1, LOCATION 1, 
EMERGENCY and LOCATION2. The TX/RX frequency, the GPS Transmission Channel and the 
Emergency Revert Channel for each of the four configured channels are listed in the table below. 





GROUP 1 


LOCATION 1 


EMERGENCY 


LOCATION 2 


Transmit/Receive 

Frequencies 


FI 


F2 


F3 


F4 


GPS Transmission 
Channel 


LOCATION 1 


None 


LOCATION 2 


None 


Emergency Revert 
Channel 


EMERGENCY 


None 


None 


None 
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4.16.7.5.1 Emergency Alarm 




Application Server 



Figure 4-35 Emergency Alarm and GPS Revert Interaction Diagram 

Figure 4-35 illustrates the channels used when an emergency is initiated and the radio is 
configured for Emergency Alarm Only with an Emergency Revert Channel and the Emergency 
Revert Channel is configured with a GPS Revert Channel. (Note: The channels are defined in the 
table in the previous section). The following describes the sequence of events. 

1 . The radio switches from the Selected Channel, fl , to the Emergency Revert Channel, f3. From 
here the radio transmits the Emergency Alarm and waits for the acknowledgement. While 
waiting for the acknowledgement, the Emergency Location Update is held in queue. 

2. Once the acknowledgement is received the radio switches back to the selected channel, 
fl, and transmits the Emergency Location Update. 

Therefore, in this scenario the GPS Revert Channel associated with the Emergency Revert 
Channel has no impact on the channel used to transmit the Emergency Location Update. 
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4.16.7.5.2 Emergency Alarm and Call 




Application Server 



Figure 4-36 Emergency Alarm and Call and GPS Interaction Diagram 

Figure 4-36 illustrates the channels used when an emergency is initiated and the radio is 
configured for Emergency Alarm and Call with an Emergency Revert Channel and the Emergency 
Revert Channel is configured with a GPS Revert Channel. (Note: The channels are defined in the 
table in the previous section) The following describes the sequence of events. 

1 . The radio switches from the Selected Channel, fl , to the Emergency Revert Channel, f3. From 
here the radio transmits the Emergency Alarm and waits for the acknowledgement. While 
waiting for the acknowledgement, the Emergency Location Update is held in queue. 

2. Once the acknowledgement is received, the radio switches to the Emergency Revert’s 
GPS Revert Channel, f4, and then transmits the Emergency Location Update. 

3. After this transmission, the radio switches to the Emergency Revert Channel, f3, and while 
not being involved in voice calls, it registers. (Note: This requires the Emergency Revert 
Channel to be ARS enabled.) 

4. After registration, periodic location updates are sent on the Emergency Revert’s GPS 
Revert Channel, f4, until the emergency is cleared. 












416 



System Design Considerations 



This configuration in Figure 4-36 is useful when a system needs to simultaneously support multiple 
Emergency Calls from multiple groups on a single Emergency Revert Channel. The placement of 
Emergency Calls on the Emergency Revert Channel and the location updates on a different 
channel significantly increases both emergency voice throughput and Location Update throughput 
while in the emergency state. It should be noted that changing the Emergency’s GPS 
Transmission Channel to either the Selected Channel, f 1 , or the Emergency Revert Channel, f3, 
removes one control station from the system. The actual configuration selected depends on actual 
customer requirements. 

4.16.7.5.3 Emergency Alarm with Voice to Follow 




Figure 4-37 Emergency Alarm with Voice to Follow and GPS Revert Interaction Diagram 

Figure 4-37 illustrates the channels used when an emergency is initiated and the radio is 
configured for Emergency Alarm with Voice to Follow with an Emergency Revert Channel and the 
Emergency Revert Channel is configured with a GPS Revert Channel. (Note: The channels are 
defined in the table in the previous section) The following describes the sequence of events. 

1. The radio switches from the Selected Channel, f 1 , to the Emergency Revert Channel, f3, and 
then transmits one Emergency Alarm. 

2. The radio stays on the Emergency Revert Channel, f3, and initiates an emergency voice 
call. During the emergency voice call the Emergency Location Update is held in queue. 
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3. Once the emergency voice call ends, the radio switches to the Emergency Revert’s GPS 
Revert Channel, f4, and transmits the Emergency Location Update. 

4. After this transmission, the radio switches to the Emergency Revert Channel, f3, and while 
not being involved in voice calls, it registers. (Note: This requires the Emergency Revert 
Channel to be ARS enabled.) 

5. After registration, periodic location updates are sent on the Emergency Revert’s GPS 
Revert Channel, f4, until the emergency is cleared. 

This configuration in Figure 4-37 is useful when a system needs to simultaneously support multiple 
Emergency Calls from multiple groups on a single Emergency Revert Channel. The placement of 
Emergency Calls on the Emergency Revert Channel and the location updates on a different 
channel significantly increases both emergency voice throughput and Location Update throughput 
while in the emergency state. It should be noted that changing the Emergency’s GPS 
Transmission Channel to either the Selected Channel, f 1 , or the Emergency Revert Channel, f3, 
removes one control station from the system. The actual configuration selected depends on actual 
customer requirements. 

4.16.8 Channel Access Configuration 

Channel access methods must be specified in the radio’s codeplug for each channel via the CPS, 
that is the TX (Transmit) parameters for each defined channel contains an Admit Criteria option 
that must be set to one of the 3 possible values described below. 

• Always, 

• Channel Free, or 

• Color Code Free. 

An Admit Criteria of Always is sometimes referred to as “impolite channel access”. An Admit 
Criteria of Channel Free is referred to as “polite to all”. Finally, an Admit Criteria of Color Code 
Free is referred to as “Polite to own color code”. In polite mode, the radio will not transmit on a 
channel if there is any activity detected on that channel. In impolite mode, the radio will transmit on 
a channel regardless of any activity on that channel. When operating in impolite mode a radio user 
will cause RF contention if there is another call on the same slot currently in progress. See 
“MOTOTRBO Channel Access” on page 22. 

Radio users provisioned for polite operation need only press their PTT to determine if they can 
transmit or not. A Talk Permit Tone or Talk Denial Tone indicates if they have been granted or 
denied access. Impolite users are allowed to transmit regardless if the channel is busy or idle, 
although they would still need to wake the repeater. 

It is important to note that the LED busy indication on the radios represents the presence of RF 
activity on the selected channel and is not specific to the digital slot currently being monitored. 
Therefore, if the LED indicates no RF activity on the channel, the radio user can be sure their slot 
is idle. However, if the LED indicates the presence of RF activity on the channel, the radio user will 
not know if their slot is actually idle or busy. If the radio users transmit when the LED indicates a 
busy channel, there is a chance their transmission will collide with another transmission. Care 
should be taken since RF collisions in digital mode most likely results in both transmissions not 
reaching their intended target. Therefore, it is highly recommend that only well trained and 
disciplined radio users are configured to have impolite channel access. 
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4.16.9 Zones and Channel Knob Programming 

The MOTOTRBO radio is capable of being programmed with up to 160 channels. Each radio has 
a 16 position selector knob/switch, in which various channels and call types can be programmed. 
In order to maximize the programming capability of the radio, the concept of “zones” is introduced. 
Zones can be created on the radio through the channels menu of the CPS. A “zone” can contain 
up to 16 channels that are mapped to the 16-position top selector knob of the portable radio or the 
channel number selector on a mobile. Radio users that require more than 16 channels must 
organize them into multiple zones in the CPS, so that they can be accessed as “zones” in the radio 
menu. From the radio menu, the user can navigate to the “zones” icon, select it, and switch to a 
different zone. When in the different zone, the 16 position selector knob/switch is now 
programmed with that zone’s channels and call types. It is recommended that the Zone should be 
given aliases that can be understood by the end user. 





System Design Considerations 



419 



4.17 Base Station Identifications (BSI) Setting 
Considerations 

Base Station Identification (BSI), sometimes referred to as CWID, is used to identify the licensee 
operating a repeater or base station. Some form of station identification is usually necessary to 
comply with the requirements of the local radio regulatory authority. 

The transmission time of the Base Station ID (BSI) is proportional to the number of characters in 
the BSI. To improve channel efficiency, it is recommended to keep the BSI length short. The 
content of the BSI needs approval from regulatory bodies (e.g. FCC in USA). Regulatory bodies 
and their regulations may vary from nation to nation, thus customers are required to understand 
their own national laws and regulations while selecting BSI characters and its length. 

BSI is available on the MOTOTRBO repeater when configured for analog or digital mode. In both 
modes, BSI is generated using a sinusoidal tone modulated on an analog FM carrier. The station 
transmits the configured Morse code alphanumeric sequence when one of two configured BSI 
timers has expired. The Exclusive BSI Timer is named TX Interval in CPS and the Mixed with 
Audio Timer is named Mix Mode Timer in CPS. The goal of these two timers is to minimize the 
impact to the ongoing traffic while still being compliant with regulatory authorities. 

TX Interval is used to configure an “Exclusive BSI” which is sent the next time the repeater de- 
keys. The Mix Mode Timer is used to configure a “Mixed with Audio” which is mixed with the 
analog audio on the channel. Mixed with Audio BSI is only utilized when configured for analog 
operation. Mixing BSI with digital audio is not supported in MOTOTRBO. 

When the Exclusive BSI Timer expires, the repeater transmits BSI the next time the repeater de- 
keys. This allows the BSI to be transmitted without disrupting on going voice, which is ideal. 
Furthermore, if the Exclusive BSI Timer expires while the repeater is not active (no subscriber 
activity) the repeater does not wake up and send BSI. Instead, it waits until the next transmission 
occurs and then transmits BSI upon de-key. BSI is only required during times of activity. Note that 
Exclusive BSI is interruptible in analog mode if the repeater receives a radio transmission. If 
interrupted, the BSI is attempted again at the next de-key. Also, whenever the repeater is forced to 
de-key due to a Time Out Timer expiring, it takes the opportunity to transmit an Exclusive BSI. 
Exclusive BSI is non-interruptible in digital and Dynamic Mixed modes. 

When the “Mixed with Audio” BSI Timer expires, the repeater performs the BSI mixed with the on 
going audio on the channel. It is very important to note that there is a two minute hold-off timer 
when the repeater first keys up. The purpose of this additional hold-off timer is to make sure that 
the BSI is not mixed with audio immediately after being de-keyed for a long duration. This delay 
gives the repeater a chance to transmit the exclusive BSI before interrupting the audio. 

Both the Exclusive BSI Timer and the Mixed with Audio Timer are reset after completion of a BSI 
transmission. 

It is recommended that the Exclusive BSI Timer (TX Interval) is set at 75% of the regulatory 
authority’s required BSI period and the Mixed with Audio BSI ( Mix Mode Timer) is set at 95% of the 
regulatory authority’s required BSI period. This way, the repeater begins attempting to send the 
BSI exclusively well before the required time. This interrupts the voice with mixed BSI as it gets 
closer to the required period if it has not found an opportunity to perform BSI exclusively. 

BSI can be completely disabled by setting both the Exclusive BSI Timer and the Mixed with Audio 
BSI Timer to 255 in the CPS. It is not a valid configuration to disable the Exclusive BSI and only 
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have the Mixed with Audio BSI enabled. This results in only Mixed with Audio BSI being sent in 
scenarios where the repeater is keyed for two minutes. 

If the Exclusive BSI Timer is enabled, and the Mixed with Audio BSI is disabled, it is possible that 
during periods of heavy use, the BSI will not be generated within the configured time period. For 
analog, it is recommended that the Mixed with Audio BSI is enabled at all times. 

Since Mixed with Audio does not operate in digital mode or in Dynamic Mixed Mode, it is possible 
that during extended periods of high activity the repeater never has a chance to de-key, and would 
therefore never have a chance to send BSI. This is more likely on a highly loaded GPS only 
repeater. This should be combated by lowering the traffic on the channel or by lowering the 
subscriber inactivity timer (SIT) in the repeater. This de-keys the repeater quicker between 
transmissions and provide a higher chance of de-key and therefore a higher chance of sending 
Exclusive BSI in the desired time frame. 

Since Exclusive BSI is interruptible in analog mode, a situation may arise where extended periods 
of high activity may cause the repeater to continually de-key, attempt BSI and then be interrupted 
by another inbound transmission. The de-keying and re-keying of the repeater causes the hold off 
timer to be reset and the Mixed with Audio BSI is never triggered unless a particular transmission 
lasts over two minutes. In this case, it is recommended that the hangtime be increased so that the 
repeater does not de-key between every transmission. If this period of high activity occurs longer 
than two minutes, the Mixed with Audio occurs, otherwise the Exclusive BSI occurs during a period 
of decreased traffic load. 

It may not be desirable to enable Mixed with Audio BSI with the use of analog data (i.e. MDC or 
VRM data). The mixing of the BSI with the analog signalling will most likely cause the signalling to 
become corrupted. 
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4.18 GPS Revert Considerations (For Single Repeater 
and IP Site Connect only) 

GPS revert, when used correctly, can significantly improve the integrated voice and location data 
performance of a system. In order to maximize location throughput while minimizing missed data 
(text, telemetry, etc.) and voice transmissions, there are a number of factors that must be 
considered. 

• Non-location update traffic should not be transmitted on the GPS Revert Channel when 
attempting to maximize the Location load on the GPS Revert Channel. 

• Avoid adding the GPS Revert Channel into the Scan List if the location load is high, as 
scanning radios will often land on this channel and qualify traffic that is not for them. This 
can slow down scanning. 

• While in repeater mode, avoid placing the alternate slot associated with GPS Revert 
Channel into the Scan List if the location load is high. Scanning radios will often land on 
this channel to qualify traffic that is not for them. This can slow down scanning. 

• For single site and IP Site Connect modes, the revert channel must be set to “Selected” 
on the radio used as the control station. 

• It is not recommended to use a portable as a control station, but if a portable is used as 
a control station then battery saver mode should be disabled since the Location Update 
messages will not be preceded with preambles. 

• Voice, data or control messages that are sent to an radio on the GPS Revert Channel 
will not be received. The radio is only on the GPS Revert Channel to transmit location 
updates and it DOES NOT qualify activity on this channel. 

• If group data is to be supported on a system, the inclusion of preambles should be 
added to minimize the occurrence of the group data message being missed while an 
radio is on the GPS Revert Channel. 

• Avoid situations where a large number of subscribers are powered on in a relatively 
short period of time as this causes a flood of registration messages that impacts the 
voice quality of service on the Selected Channel during the registration process. See 
“GPS Revert and Loading” on page 296 for recommendations on minimizing impact 
when using Motorola applications. 

• In order to minimize users from inadvertently changing a radio to the GPS Revert 
Channel, it is recommended that the GPS Revert Channel(s) is placed in a different 
zone than the primary voice and data channel(s). 
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4.19 Enhanced GPS Revert Considerations 

Below is a summarized list of items to keep in mind when configuring the Enhanced GPS feature 
in a system: 

• GPS and raw data messages from the option board and non-IP peripheral devices are 
supported over the Enhanced GPS Revert channel for one-time and periodic 
transmissions. 

• If a repeater slot configured as “Enhanced GPS Revert” is power cycled, the 
subscriber’s GPS updates scheduling begin again because the scheduling information 
is not stored in the repeater’s memory. 

• The window size on all repeaters and subscribers should match. 

• GPS data must be configured as “unconfirmed” on the GPS Revert channel on the 
radio. 

• Enhanced GPS only needs to be enabled on the Enhanced GPS Revert channel of the 
radio, and not on the Home channel. However, if header compression is planned for 
use, then this feature needs to be enabled on the Home channel instead. 

• For single site and IP Site Connect modes, the revert channel must be set to “Selected” 
on the radio used as the control station. 

• Only Enhanced GPS-configured subscribers can work on the Enhanced GPS Revert 
channel. This feature do not support the following configurations: 

• Legacy revert repeaters working with Enhanced GPS Revert subscribers 

• Legacy subscribers working with Enhanced GPS Revert repeaters 

• Legacy repeaters working with Enhanced GPS Revert repeaters in IP Site 
Connect mode 

• An application making a periodic request with the Enhanced GPS feature should only 
make a request with a cadence of 0.5, 1,2,4, and 8 minutes. When the window size is 1 
or 2 with the CSBK data feature enabled, the application should only make a request 
with a cadence of 7.5, 15, 30, 60 and 120 seconds. If the cadence is different, the 
subscriber responds with a LRRP error message “PROTOCOL_ELEMENT 
JMOTSUPPORTED”. This is also valid for persistent requests. 

• A radio can only have one periodic request at a time. If “Persistent Storage” is enabled 
on the radio, the user must send a Triggered-Location-Stop-Request from the 
application before sending a new periodic request. If the user needs to change the 
application, then the user should either delete all requests from the Persistent Storage 
via the CPS or ensure that a Triggered-Location-Stop-Request is sent from the first 
application before a new periodic request is sent by the new application. 

• The ARS initialization delay feature is recommended if a customer plans to use 
Enhanced GPS in a system that has many subscribers powering on at the same time 
and all of them need ARS. This helps to reduce ARS collisions at power up. More details 
in 2. 4. 3. 6. 2 ARS Initialization Delay. 

• If CWID is enabled, no GPS updates will be sent out while CWID is being transmitted. 
The user can choose to disable CWID via the CPS if needed. 

• If there are free windows available in a system, these may be used by the repeater to go 
into hibernate mode. Hence, reserving more one-time windows (running at 60% or 45% 
capacity) increases the chances of hibernation. When the window size is reduced to 1 or 
2 with the number of subscribers and GPS update rate unchanged, free windows 
available in a system increase, hence the chances of hibernation increase accordingly. 
CPS configuration “Shared Channel Frequency” increases the chances of hibernation 
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on the Enhanced GPS channel too. However, this leads to more channel collision when 
the subscribers send window requests, because the configuration causes the free 
windows to concentrate at the end of a data frame. Therefore the “Shared Channel 
Frequency” configuration may not be necessary when the CSBK data feature is enabled 
with window size 1 or 2. 

• The CSBK data feature is recommended when high system throughput is required. 
Refer to Table 4.1 . However, there are some limitations to this feature. 
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4.19.1 Single Site Mode 

In Single Site Conventional mode, all location responses are sent over the repeater slot configured 
as Enhanced GPS revert. The following two configurations are possible: 

1 . One slot configured as Enhanced GPS Revert and another slot for voice and data: In 

this configuration, only location responses are sent over the Enhanced GPS Revert 
channel. Voice, text messages, ARS, and other data are sent over the other slot. 

2. Both slots configured for Enhanced GPS Revert: This configuration is recommended if 
the number of subscribers sending location updates exceeds the capacity of one 
Enhanced GPS slot. In this case, a second repeater would be needed to support voice, 
text messages, ARS and other data. 

4.19.2 Capacity Plus and Linked Capacity Plus Modes 

In Capacity Plus and Linked Capacity Plus modes, all location responses and ARS registration 
messages are sent over the repeater slot configured as Enhanced GPS revert. A data revert 
repeater can be configured for Enhanced GPS revert and the following two configurations are 
possible via the CPS: 

1. One slot configured as Enhanced GPS Revert and another slot for Data Revert: In 

this configuration, GPS and ARS registration data are sent over the slot configured as 
Enhanced GPS revert. All other data and voice either goes on the Data Revert slot or on 
the Trunked Channels. 

2. Both slots configured for Enhanced GPS Revert: This configuration is recommended if 
the number of subscribers sending location updates exceeds the capacity of the 
Enhanced GPS throughput of one slot. In this configuration, a separate data revert 
repeater or trunked repeaters can be used for other data such as voice, text messages, 
and server bound data. 

4.19.3 IP Site Connect Mode 



In IP Site Connect mode, GPS updates are routed on the slot configured as wide area Enhanced 
GPS revert slot. Two configurations are possible via the CPS for a wide area Enhanced GPS 
Revert system: 

1 . One slot configured as Enhanced GPS Revert and another slot for voice and data: In 

this configuration, one slot of all the peers in the network is configured for Enhanced GPS 
operation while the other slot can be used for voice, ARS, text messages, and all other 
server data. 

2. Both slots configured for Enhanced GPS Revert: This configuration is recommended if 
the number of subscribers sending location updates exceeds the capacity of the 
Enhanced GPS throughput of one slot. In this configuration, the entire IP Site Connect 
system will be used for sending location updates only. 
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4.1 9.3.1 Other Considerations 

• Only one repeater in the wide area Enhanced GPS Revert system should select a value 
for “Period Window Reservation” in the CPS. All other repeaters should choose a value 
of “None” for this field. 

• If the inter-repeater communication delay is more than 60 milliseconds, then the window 
size should exceed 7. 
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4.20 Enhanced Channel Access Consideration 

The Enhanced Channel Access (ECA) feature is a channel access procedure in which a call 
initiating radio transmits a channel access request and listens on the channel to determine the 
status of the request. The radio continues with the transmission of the call only when access to the 
channel is obtained. Only one of the requesting radios can obtain channel access to proceed with 
the call transmission. The ECA provides the ability to reserve a channel over-the-airfor one of the 
call initiating radios, and provide exclusive access to that radio for a short duration. 

Enhanced Channel Access is a Motorola proprietary feature and is not defined in the DMR 
standard. It is applicable only in repeater mode (Single Site Conventional and IP Site Connect 
only) of operation. It is not required in Capacity Plus or Linked Capacity Plus modes because their 
call startup processes implicitly including ECA. 

4.20.1 Enhanced Channel Access Advantages 

• Improves voice/data call success rate by minimizing over-the-air call collisions due to 
multiple radios keying up within close proximity 

• Prevents call transmission when the radio is out of inbound range (but within the 
outbound range) and provides correct call status indication to the user 

• Improves the GPS data success rate on the GPS revert channel by minimizing collisions 

• Prioritized channel access for an initiating radio to proceed with a call, among other 
radios 
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4.20.2 Enhanced Channel Access Limitations 



Enhanced Channel Access is configurable on the radio and can be enabled or disabled on a 
conventional digital channel, IPSC LACs, IPSC WACs and GPS/Data Revert Channel. However, 
ECA is built into Capacity Plus Trunked Channels and not configurable by the user. This feature is 
disabled and not required when the Enhanced GPS feature is enabled on the channel, because 
each radio transmits during an assigned time window. 

When enabled in the radio, the repeater supports ECA on conventional digital channels, IPSC 
LACs, IPSC WACs and Capacity Plus Data Revert Channels. However, the repeater does not 
support this feature on Enhanced GPS and DMM channels. 

When enabled, ECA is applicable only to polite transmissions initiated by the radio user. If the 
Admit Criteria in the radio is configured as Channel Free or Color Code Free, the radio applies the 
ECA procedure when a voice call is initiated. If the Admit Criteria is configured as Always, the ECA 
procedure is not applied. Data and CSBK calls are always polite transmissions, regardless of the 
configured Admit Criteria. Therefore, ECA is applied during call transmission if the feature is 
enabled. However, this slightly increases the system/voice access times for voice calls and latency 
for data, CSBK calls. 

When a radio auto roams to a new site in an IPSC system configuration, the radio applies the ECA 
configuration from the roamed channel and the Admit Criteria from the selected channel. 

For phone calls occurring in all system configurations, ECA is enabled by default to achieve 
optimum performance. It is also recommended to enable ECA on all radios accessing the channel 
to derive maximum benefit from the feature. For a correct and reliable operation, it is strongly 
recommended to upgrade the repeater firmware version to R01.08.00 or later, before initiating 
calls with the ECA feature enabled on the radio. 
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4.21 Failure Preparedness 

4.21.1 Direct Mode Fallback (Talkaround) 

A repeater channel is defined by having different receive and transmit frequencies, and any 
channel that is programmed with the CPS to have different receive and transmit frequencies will 
be considered to be a repeater channel and the MOTOTRBO radio will expect a repeater 
operating on that channel. The radio user will get an access-denied tone if there is no repeater 
available or if the radio is out of range of the repeater. Channels defined as repeater channels in 
CPS can be modified to operate in Talkaround mode via user selection from the menu or a 
programmable button. When a repeater channel is thus modified to operate in Talkaround mode, 
the transmit frequency is set equal to the receive frequency, and it effectively becomes a direct 
mode channel. The system now performs similarly to the direct mode topologies we have 
previously described. 

Occasionally, Talkaround mode is incorrectly referred to as “direct mode”, but they are different. 
Direct mode is a mode of operation in a system environment whereby no repeaters are present. 
Talkaround mode is direct radio-to-radio communication for systems that primarily use a repeater 
but occasionally communicate without a repeater. 

4.21 .2 Uninterrupted Power Supplies (Battery Backup) 

To determine the UPS capacity you will need, follow these simple steps: 

1 . List all equipment to be protected by the UPS on a worksheet. 

2. Read the nameplate data on each of the devices listed. Write down the voltage and 
amperage for each device. 

3. Multiply the voltage by the amperage of each device to calculate the Volt/Amps (VA). 
Some equipment, such as PC power supplies, may be marked with a power consumption 
measured in Watts. To convert Watts to VA, simply divide Watts by 0.65 (for a power factor 
of 0.65), or multiply by 1.54. The power factor refers to the relationship between the 
apparent power (volt-amps) required by the device and the actual power (watts) produced 
by the device. 

4. Total the VA for all devices you want to protect with the UPS and enter it in the “Subtotal” 
field. 

5. Multiply the subtotal found in Step 4 by 0.25 and enter it as the “Growth Factor”. This 
number takes into account room for future growth. This growth factor allows for a 5% rate 
of growth for each year over a five-year period. 

6. Add the “Growth Factor” to the “Subtotal” to get the “Required VA”. Now you can select the 
appropriate UPS model by choosing a model that has a VA rating at least as large as the 
“Required VA” that you calculated. 
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4.22 Dynamic Mixed Mode System Design Considerations 

During Dynamic Mixed Mode operation, the repeater dynamically switches between analog and 
digital modes to transmit analog and digital calls. It is only supported in Single Site Conventional 
mode. A Dynamic Mixed Mode channel is a programmable channel in the repeater and the 
channel can be added using the CPS. 

To support DMM feature in the repeater, the following design rules have been laid out. 

1. Once a call type (analog or digital) has been qualified, the repeater will not try to qualify 
another call type until the current call is complete, including the call hang time hang and 
channel hang time. For digital calls, the hang time needs to be expired on both logical 
channels. Analog call type includes an over-the-air call or any operation (PTT, pin knockdown) 
on the 4-wire Analog Repeater Interface (ARI) trying to access the repeater. 

2. Analog console device(s) are supported only when the repeater has not qualified an over- 
the-air digital call. An audible alert (channel busy tone) is generated over the speaker and 
Rx audio pins on the 4-wire repeater interface to indicate that the channel is busy and that 
the console access has been denied. 

3. Only PL (DPL/TPL) squelch type repeat is supported in MOTOTRBO repeater as CSQ 
repeat is not supported. However, if the receive squelch type is configured to CSQ, the 
received audio is sent over the Rx audio accessory pin for community repeater operation. 

4. To ensure proper Dynamic Mixed Mode operation, only exclusive CWID transmission is 
supported in MOTOTRBO repeater operating in Dynamic Mixed Mode, while mixed CWID 
is not supported in order to be compliant with the digital mode of operation. Furthermore, 
the exclusive CWID transmission cannot be interrupted by either over-the-air or repeater 
accessory PTT transmission. 

4.22.1 Dynamic Mixed Mode System Configuration Considerations 

A few repeater and subscriber configuration recommendations have been laid out to ensure 
proper Dynamic Mixed Mode system operation. 

1. For analog repeater operation, configure the Rx and Tx squelch types as PL (TPL or DPL) in 
the repeater. The Dynamic Mixed Mode repeater does not repeat if Rx squelch is configured 
as CSQ. 

2. Configure the Tx and Rx squelch types as PL (TPL or DPL) in both legacy analog and 
MOTOTRBO radios. If Rx squelch type is configured as CSQ, the radios will unmute to 
digital transmission and play out digital noise. 

3. Configure the admit criteria of both analog and digital radios to be polite to each other. 
MOTOTRBO radio configuration recommendations are provided in the table below. For 
legacy analog radios, it is recommended to configure the polite rule as Busy Channel 
Lockout on Wrong PL code. 
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4. If MOTOTRBO radios need to communicate on their digital channels with the legacy 
analog radios or with MOTOTRBO radios on analog channels, the digital channels can be 
configured to scan for analog channels by way of scanning DPL or TPL. Scanning may 
result in an initial audio truncation and the truncation depends on the number of scan 
members in the Scan List. To prevent loss of digital data transmission, it is recommended 
to configure the preamble duration as per the recommendations listed in “Scan 
Considerations” on page 76. 

5. It is recommended to have a digital channel as the home channel and add the analog 
channels to the Scan List. This is because the scanning radios can receive data 
messages only on the home channel. 

6. Priority sampling and channel marking CPS configurations are recommended to be 
disabled in Dynamic Mixed Mode system. Refer to “Priority Sampling” on page 74 and 
“Channel Marking” on page 75 for more details. 

Some of the CPS configuration recommendations are listed below. 



Repeater 

Configuration 


Description 


Channel 


Add a new DMM channel and program the parameters in that channel. 


Repeater Type 


Configure this to Single Site. IP Site Master and IP Site Peer configurations are 
not supported in Dynamic Mixed Mode system. 


SIT 


Configure SIT so that the channel hang time (SIT - Group/Private/Emergency 
Call Hang time) is as small as possible. This allows analog users to get almost 
immediate channel access once a digital call ends. 

Channel Hang Time = SIT - Call Hang Time 

Example: When SIT = 7 seconds and Group Call hang time = 5 
seconds, Channel hang time = 2 seconds for that group 
voice call. 

Example: When SIT = 7 seconds and Private Call hang time = 4 
seconds, Channel hang time = 3 seconds for that private 
voice call. 


Rx Squelch, 
Tx Squelch 


Configure this to TPL or DPL for non-community repeater operation. Received 
audio is repeated out. 

OR 

Configure this to CSC for community repeater operation. Received audio will 
not be repeated out. The audio is instead sent over the Rx audio accessory 
pin. 


Strip PL 


Check this box to ensure that PL is not added to CWID. 
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Radio 

Configuration 


Description 


TX Preamble 
Duration 


This duration depends on the number of scan members in the Scan List. Refer 
to “Scanning and Preamble” on page 77 for more details. 

If the radios are required to scan analog channels, then it is recommended that 
the digital channels scan as few in number of analog channels as possible. 


Rx Squelch Type 


Configure this to TPL or DPL. 

If configured for CSQ, the radios unmute to all digital transmissions and play 
digital noise. 


Tx Squelch Type 


Configure this to TPL or DPL. 

Repeater does not repeat if there is no PL in its received signal. 


Admit Criteria 


Configure Analog channel Admit Criteria to “Correct PL”. 

Refer to “Polite to Other Analog System Operation (Admit Criteria of “Correct 
PL”)” on page 24 for more details. 

Configure Digital channel Admit Criteria to “Channel Free”. 

Refer to “Polite to All Operation (Admit Criteria of “Channel Free”)” on page 23 
for more details. 


Priority Scanning 


Disable priority scanning on all scan members in the Scan List. 


PL Type (in Scan 
List) 


It is recommended to configure this to Non-Priority channel so that PL decoding 
is performed on non-priority Scan List member channels. 


Channel Marker 
(in Scan List) 


Disable channel marker. 


Talkback 


Check this box to allow the radio to talk back on the channel it unmuted during 
the scan. 


Tx Designated 
Channel 


Choose “Selected” or one of the configured scan members as needed. 
However, it is not recommended to configure the “Last Active Channel”. 


Analog Hang 
Time 


Configure this value to as small as possible so that the radios can start 
scanning immediately. 


Digital Hang Time 


In a DMM system, the repeater reserves the channel for digital calls till the end 
of SIT + 1 second. Since no analog calls are allowed until then, it is 
recommended to configure this to SIT + 1 second. 


RSSI Threshold 


Adjust this value based on the RF interference level. Refer to section 2.2.3 for 
a more detailed description of this field. 



4.22.2 Loading Considerations in a Dynamic Mixed Mode System 

A digital transmission may occupy a repeater's physical channel for twice as long as an analog 
transmission since there are 2 logical digital channels on each physical channel and transmissions 
may occur on each logical channel one after another. With a relatively small number of digital 
radios in Dynamic Mixed Mode system, it is recommended to configure digital radios to operate on 
only one logical channel during migration to provide fair channel access between analog and 
digital transmissions. As more digital radios start replacing the analog radios, distribute some of 
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the digital radios to use the other logical channel. It is important to note that heavy users of one 
category (analog or digital) will occupy the channel longer than the users in the other category 
when they are in a polite system configuration. 

It is recommended to keep digital channel hang time to the minimum, or as low as possible, to 
allow fair channel access between analog and digital calls. However, with a smaller channel hang 
time, the system access time for digital calls may increase due to the fact that the radios need to 
wake up the repeater before calls. 
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4.23 Over-the-Air Radio Programming Design 
Considerations 

4.23.1 Advanced Over-the-Air Radio Programming Configurations 

The configuration software has some basic deployment options when OTAP is desired. The RM 
application works the same regardless of the underlying system architecture. There are no 
settings within the application for the specific system configuration, besides those to be 
programmed into the radios. This section highlights some special system configurations and some 
considerations that should be taken when utilizing them. Unless specifically noted, these 
configurations can be used with or without a DDMS, with or without a remote RM Client, and up to 
16 control stations. 

NOTE: Control station deployments with multiple channels require an MCDD and ARS messages 
from the radios to update the routing. 

4.23.1.1 Control Station Configuration 

The control station must be configured with the appropriate system type parameters for the 
channel or system being monitored. Additionally, the control stations connected to the RM Server 
and Device Programmer must be configured with all the following parameters: 

• Confirmed data enabled 

• UDP header compression disabled 

• All voice privacy keys utilized in the system 

• Unique radio ID 

• ECA enabled 

Failure to properly set these parameters could result in diminished coverage, longer delivery and 
retrieval times, or no communication at all. These settings apply to all system types. 

UDP header compression increases the number of lower layer headers, which decreases 
reliability. The decrease in reliability is not worth the benefits of the compression in case of large 
messages. ECA minimizes the impact of voice transmissions colliding with OTAP data. It is 
suggested that ECA is enabled on all radios within the system if OTAP is utilized. 

In some configurations, the multiple control stations used by RM may have matching radio IDs. 
However, their radio ID should not match that of another radio in the field. 

It is recommended to use next generation MOTOTRBO mobiles (R02. 10.00 or later) as RM control 
stations, since they assure minimal impact to the radio system performance during over-the-air 
transmissions. Older MOTOTRBO mobiles, when used as control stations, do not have the ability 
to prioritize voice over data traffic. 

If no MCDD is utilized, a static, persistent route is required in the PC so that messages are routed 
out of the control station and not out of any other network interface. 
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4.23.1.2 MOTOTRBO Network Interface Service (MNIS) Configuration 

The MNIS must be configured with all the following parameters: 

• Confirmed data enabled 

• UDP header compression disabled 

• All voice privacy keys utilized in the system 

• Unique MNIS Application ID (no radio ID duplicate) 

Failure to properly set these parameters could result in diminished coverage, longer delivery and 
retrieval times, or no communication at all. These settings apply to all system types. 

UDP header compression increases the number of lower layer headers, which decreases 
reliability. The decrease in reliability is not worth the benefits of the compression in case of large 
messages. 

The MNIS Application ID is the “radio ID” the MNIS uses to monitor and transmit on the radio 
network. The MNIS Application ID is similar to the radio ID of the control station. Just like radio ID 
of the control stations, the MNIS Application ID should not match the radio ID of another radio in 
the field. 
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4.23.1.3 Conventional Configurations 



There is little difference between the basic deployments in conventional system types such as 
direct mode (12.5 or 6.25e), single site repeater, and IP Site Connect. The only settings that are 
different are the system specific parameters of the control station or MNIS. Below are three basic 
control station examples. 
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Figure 4-38 Multi-Channel RM Application with Control Stations in Direct Mode 
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Figure 4-39 Multi-Channel RM Application with Control Stations in Single Site Repeater Mode 




Figure 4-40 Multi-Channel RM Application with Control Stations in IP Site Connect Mode 
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When deploying the MNIS, single site repeater and IP Site Connect configurations are generally 
the same. The MNIS can connect to eight conventional systems. This means eight IP Site Connect 
systems (each with numerous sites), or eight Single Site repeaters, or any combination of IP Site 
Connect systems and Single Site repeaters that total up to eight. Unlike the control station 
deployment, the PC that contains the MNIS, DDMS, and RM application do not need to be within 
RF coverage of any repeaters. 

In Figure 4-41 below, the two repeaters shown could be two single site repeaters, or two sites of 
one IP Site Connect system. 




Figure 4-41 Multi-Channel RM Application with MNIS in Single Site or IP Site Connect Mode 



Radios are capable of manually changing between channels that are monitored by control stations 
or the MNIS during an active over-the-air session. Radios can also roam between sites of an IP 
Site Connect system during an active over-the-air session. If radios move to channels not 
monitored by control stations or the MNIS, the over-the-air operation stops. When the radio returns 
to the monitored channel, and registers its presence, the over-the-air operation starts again. 









System Design Considerations 



437 



4.23.1.3.1 RF Isolated Single Site Repeaters 

To communicate with single site repeaters that are not within RF coverage of each other, multiple 
PCs with control stations must be set up, or set up one PC with a MINIS. Depending on RF 
coverage, one PC may be within RF coverage of multiple sites. In that scenario, more control 
stations can be connected. 

A remote RM Client can be used from a centralized location to contact both RM Servers. 

NOTE: It is important to note that one radio should not be configured in more than one RM Server. 
Therefore if there are radios that move from one site to another, monitored by a different 
RM Server, Device Programmer and control stations, they must only be populated in one 
of the RM Servers. Radios that do move between sites that are monitored by different RM 
Servers/Device Programmers can only be contacted when they are on the channel 
monitored by their RM Server. There is a DDMS and MCDD on both PCs. 




Figure 4-42 RM Application with Control Stations Covering RF Isolated Single Site Repeaters 
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A Remote Device Programmer configuration can be utilized if a centralized RM Server is required, 
as shown in Figure 4-43. This configuration requires a stable, direct network connection between 
the RM Device Programmers and the RM Server. 





Figure 4-43 RM Application with Control Stations Covering RF Isolated Single Site Repeaters Using 

Remote Device Programmers 



When deploying a MNIS, communicating with single site repeaters that are not within RF coverage 
of each other is much simpler. The MNIS can connect to eight conventional systems. The RM 
Client can be remote from the RM Server, and the RM Server can be remote from the RM Device 
Programmer(s). Since the MNIS can be remote from the system, all RM subcomponents can be 
installed on the same PC at a remote location. 
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Figure 4-44 RM Application with MNIS Covering RF Isolated Single Site Repeaters 

4.23.1.3.2 Local Channel Support on IP Site Connect 



On IP Site Connect systems that have local area channels at some of the sites, there are a couple 
of configuration options available. 

If the radios usually operate on the wide area channels, and infrequently change to the local 
channels, it may be easiest to have the RM and control stations at one site monitoring the wide 
area channels only. 

In this case, radios can only be programmed over-the-air when they become present on the wide 
area channel monitored by the control stations. When they are on the local channels, they are 
considered absent. 

If some of the radios always remain on the local channels, then it is necessary to have control 
stations monitoring them in order for the RM to contact the radios on that channel. Depending on 
RF coverage of each site and the location of the RM and control stations, all sites may not be 
reachable via RF from one location. Therefore a second PC with control stations must be set up 
within RF coverage of the local channels of other sites. 

A Remote Device Programmer configuration can be utilized as shown in Figure 4-36. A stable, 
direct network connection between the RM Device Programmers and the RM Server is required. 
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Figure 4-45 RM Application with Control Stations in IP Site Connect Mode Covering Local Channels with 

Remote Device Programmers 

When deploying a MNIS, communicating with local channels of an IP Site Connect system is much 
simpler. One MNIS can communicate with the wide area and local area channels over the IP 
network. Therefore, there is no need for a second computer to cover the local channels. 

The RM Client can be remote from the RM Server, and the RM Server can be remote from the RM 
Device Programmer. Since the MNIS can be remote from the system, all RM subcomponents can 
be installed on the same PC at a remote location. 
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Figure 4-46 RM Application with MNIS in IP Site Connect Mode Covering Local Channels 

4.23.1.3.3 Dynamic Mixed Mode (DMM) 

The RM can configure radios over-the-air that are operating in digital mode on a DMM system. 
There are some limitations on performance. For example, when operating in DMM, analog voice 
transmissions do not have priority while an over-the-air operation is occurring. Once an over-the- 
air operation has started in digital mode, the repeater is kept in digital mode for its duration. This 
means an analog transmission cannot gain access to the system and receives a busy indication 
for the duration of the operation. 

To mitigate this, a pacing option can be set within the RM Device Programmer so that there are 
times of idle between each delivery or retrieval. The pacing duration is suggested to be greater 
than five minutes. This may provide the analog radio an opportunity to see an idle channel more 
often. It is recommended that over-the-air configurations occur during non-peak hours, especially 
when operating on a DMM system. 

During an analog or digital voice transmission, the RM Application data is queued in the control 
station. 

The MNIS does not support communication with repeaters operating in Dynamic Mixed Mode 
(DMM). 

NOTE: Because some radios may be scanning while operating in DMM, the data preamble on the 
control station may need to be increased to reach the target radios. This increases the size 
of the data messages over-the-air, hence the overall time taken to perform an operation 
may increase. Follow the standard rules for setting the preamble duration versus the 
number of scan members. 
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Figure 4-47 RM Application in Dynamic Mixed Mode 

4.23.1.4 Trunking Configurations 
4.23.1.4.1 Capacity Plus 



OTA 
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Capacity Plus has four different control station configurations available. The major difference 
between the control station configurations is how presence services are handled. The four 
configurations are: 

• One trunked control station without presence 

• One trunked control station with presence 

• One trunked control station and conventional control stations with presence 

• One trunked control station and data revert control stations with presence 

There are three different MNIS configurations available for Capacity Plus: 

• MNIS without Presence 

• MNIS with Presence and No Data Revert 

• MNIS with Presence and Data Revert 
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4.23.1 .4.1 .1 One Trunked Control Station without Presence 

The simplest trunking configuration is without utilizing presence at all. Without a DDMS, the RM 
attempts to contact each radio one by one, regardless if they are present on the system or not. 
Although this is not optimized, it requires the least amount of infrastructure. 

Only one trunking control station is required in this configuration. Since the RM sends one 
message at a time, there is no need for multiple control stations. Therefore, loading on a Capacity 
Plus system is usually not an issue. 

Recall that MCDD is never used in Capacity Plus since the repeaters handle mobility. A persistent 
static route is required in the PC so that messages are routed out of the trunking control station 
and not out of any other network interface. 
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Figure 4-48 RM Application in a Capacity Plus System with No DDMS 
and One Trunked Control Station 
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4.23.1 .4.1 .2 One Trunked Control Station with Presence 

This configuration is the same as the previous, but utilizing presence and a DDMS. The upside to 
this is that only one control station is required and that the RM only attempts radios that are 
present. The down side is the ability to receive presence registration messages effectively. For 
example, if two radios power on within a short period of time, both attempt to deliver their presence 
registration messages to the same trunked control station, but only one is successful at a time. 
The unsuccessful radio tries again and eventually becomes successful. As the number of radios 
that simultaneously registers grows, this configuration could lead to a slower registration time. If 
this becomes a problem, consider increasing the radio’s ARS Initialization Delay timer on the 
presence registrations. This further distributes the registration attempts. 

Therefore, this configuration is more optimized in performing over-the-air configurations, but less 
optimized in the presence registration process. 
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Figure 4-49 RM Application in a Capacity Plus System with a DDMS and One Trunked Control Station 
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4.23.1.4.1.3 One Trunked Control Station and Conventional Control 
Stations with Presence 

To further optimize the reception of simultaneous presence registrations, conventional control 
stations could be installed on every trunked channel for the sole purpose of receiving simultaneous 
presence registration messages. Outgoing RM application messages are sent through a single 
trunked control station via a static route in the PC. The conventional control station’s radio ID 
should match the ARS radio ID programmed in the radios and the trunked control station would 
have a unique radio ID. Although this configuration is optimized for presence registration, 
substantial additional hardware is required. 
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Figure 4-50 RM Application in a Capacity Plus System with a DDMS and One Trunked and Numerous 

Conventional Control Stations 
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4.23.1.4.1.4 One Trunked Control Station and Data Revert Control Stations 
with Presence 

The RM application operates with control stations on Capacity Plus systems that have existing 
data revert channels, but it is important to note that the OTAP data is not sent on the revert 
channel. It is expected that the data revert channels exist for other data applications. It is assumed 
that since OTAP happens rarely, a dedicated data revert channel is unlikely. Recall that no other 
over-the-air data application is supported on the PC with the RM Server and Device Programmer. 

In this configuration, the presence registration messages are sent to the data revert channels, 
while the OTAP data is sent on the trunked channels. This configuration only requires conventional 
control stations to monitor the revert channels, therefore drastically reducing the number of 
required control stations. There needs to be one trunked control station for the OTAP data. 
Outgoing RM messages are sent through a single trunked control station. A static route is required 
in the PC. The conventional control stations would have the ARS radio ID programmed in the 
radios and the trunked control station would have a unique radio ID. 





IP 


DDMS 


IP 




Radio 








0) 


Management 

(RM) 




IP 




Q 

CO 

C/3 

z> 









Trunked 

Control 

Station 



Revert 

Control 

Station 



Radio IDs = 2 



Trunked Ch 1 



Trunked Ch2 



Trunked Ch3 



Trunked Ch4 



Trunked Ch5 



Trunked Ch6 




ARS Radio ID = 2 



Data Revert 
Chi 



Data Revert 
Ch2 



IP 



Figure 4-51 RM Application in a Capacity Plus System with a DDMS, 
Data Revert Channels, and Control Stations 
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4.23.1.4.1.5 MNIS without Presence (DDMS) 



The simplest trunking configuration is without utilizing presence at all. Without a DDMS, the RM 
attempts to contact each radio one by one, regardless if they are present on the system or not. 
Although this is not optimized, it is the simplest configuration. 
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Figure 4-52 RM Application in a Capacity Plus System with a MNIS 
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4.23.1.4.1.6 MNIS with Presence and No Data Revert 

This configuration is the same as the previous, but utilizing presence and a DDMS. The MNIS 
does not have the disadvantages of the control station configuration when it comes to the ability to 
receive presence registration messages effectively. The MNIS can receive all presence 
registration messages, even if numerous messages are sent to it on different trunked channels at 
the same time. Recall that the control station configuration requires a control station monitoring 
every trunked channel to accomplish this. Therefore, use of the MNIS in this configuration can 
drastically decrease cost and complexity. 

The MNIS application ID should match the ARS radio ID in the radio. Therefore all ARS messages 
will be targeted towards and received by the MNIS. 
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Figure 4-53 RM Application in a Capacity Plus System with a MNIS and a DDMS 
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4.23.1 .4.1 .7 MNIS with Presence (DDMS) and Data Revert 

The RM application operates with the MNIS on Capacity Plus systems that have existing Data 
Revert Channels, but it is important to note that the OTAP data is not sent on the revert channel. It 
is expected that the Data Revert Channels exist for other data applications. It is assumed that 
since OTAP happens rarely, a dedicated Data Revert Channel is unlikely. 

In this configuration, the presence registration messages are sent to the Data Revert Channels, 
while the OTAP data is sent on the Trunked Channels. The MNIS can receive and send OTAP 
messages on the Trunked Channels and the presence registrations on the Data Revert Channels 
without additional equipment. 

As previously mentioned, it is expected that the Data Revert Channels in this configuration exist 
for other data applications. See “Coexistence with Third-Party Data Applications” section for more 
details. 
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Figure 4-54 RM Application in a Capacity Plus System with a MNIS and a DDMS, 

and Data Revert Channels 
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4.23.1.4.2 Linked Capacity Plus 

There is little difference in the basic deployments between Capacity Plus and Linked Capacity 
Plus. As in conventional, the RM itself is unaware of the underlying architecture. 

Therefore, all previous Capacity Plus configurations for the RM are also supported in Linked 
Capacity Plus. This is primarily true because individual data is always sent as wide area. If utilizing 
wide area data revert channels, the RM Server, Device Programmer and control stations only need 
to be within coverage of one of the sites. Radios send their presence registration to the data revert 
channels, which in turn routes the data back to the site where the conventional control stations are 
monitoring. 




Figure 4-55 RM Application with Control Stations in a Linked Capacity Plus System with Presence 

(DDMS) and Wide Area Data Revert Channels 

If utilizing local area data revert channels at one or more sites, there must be a separate Device 
Programmer and control stations set up within RF coverage of that site. It requires a stable, direct 
network connection between the RM Device Programmers and the RM Server. 
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Figure 4-56 RM Application with Control Stations in a Linked Capacity Plus System with Presence 

(DDMS) and Local Area Data Revert Channels 
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If utilizing a MNIS with wide or local area Data Revert Channels, the RM Application (Client, 
Server, and Device Programmer) can all be remote from other LCP sites. The OTAP data will be 
routed to the appropriate site over the IP network. 

Radios send their presence registration on the Data Revert Channels (wide or local), which in turn 
routes the data back to the MNIS over the IP network. 
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Figure 4-57 RM Application with MNIS in a Linked Capacity Plus System with Presence and 
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4.23.1 .5 Coexistence with Third-Party Data Applications 

OTAP is supported on systems that have third-party data applications, but there are some special 
considerations and configurations required. There are three combinations supported: 

• RM and Third-Party Data Application with Control Stations 

• RM and Third-Party Data Application with MNIS 

• RM with MNIS and Third-Party Data Application with Control Stations 

The following sections describe the three different combinations. 

4.23.1 .5.1 RM and Third-Party Data Application with Control Stations 

It is important to understand that although supported on the same system, the RM Device 
Programmer are not supported on the same computer as a third-party data application when using 
control stations. 

If a third-party data application utilizes a different message routing strategy than what is used by 
the RM and the MCDD, message delivery may become unreliable if on the same computer. 
Therefore, the RM Device Programmer should be installed on a different computer with a different 
set of control stations than another third-party data application utilizing control stations. 

Even if on different computers, a system level conflict may still remain. The RM application can 
utilize the ARS messages sent by the radios to track presence and mobility. These messages are 
sent from the radios to the control stations associated with the RM. The ARS messages are used 
by the MCDD to keep track of which radios are present and which channel they are present on. 

If the third-party data application does not utilize the ARS, then the radios can be programmed to 
send their ARS messages to the RM control stations and no additional considerations are 
required. 

If the third-party data application utilizes the ARS, then the radios must remain programmed to 
send their ARS messages to the control stations connected to the third-party data application. In 
order for the RM to also receive the ARS messages, the control stations associated with the RM 
must be programmed with an ARS Monitor ID that matches the radio ID of the third-party data 
application’s control stations. Additionally, the DDMS used by the RM must have the “Passive” 
option enabled. A section below describes the passive presence and the ARS Monitoring ID 
configuration further. 

If operating RM without presence and a DDMS, a configuration utilizing passive presence is not 
required. 

4.23.1.5.2 RM with MNIS and Third-Party Data Application with Control 
Stations 

The MNIS should not be installed on a computer that also contains control stations. These two 
methods have conflicting routing methods. Therefore, the RM Device Programmer and MNIS 
should be installed on a different computer than another third-party data application utilizing 
control stations. 
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Even if on different computers, a system level conflict may still remain. The RM application can 
utilize the ARS messages sent by the radios to track presence and mobility. These messages are 
sent from the radios to the MNIS associated with the RM. The ARS messages are used by the 
DDMS to keep track of which radios are present and which channel they are present on. 

If the third-party data application does not utilize ARS, then the radios can be programmed to send 
their ARS messages to the RM MNIS and no additional considerations are required. 

If the third-party data application utilizes ARS, then the radios must remain programmed to send 
their ARS messages to the control stations connected to the third-party data application. In order 
for the RM to also receive the ARS messages, the MNIS associated with the RM must be 
programmed with an ARS Monitor ID that matches the radio ID of the third-party data application’s 
control stations. Additionally, the DDMS used by the RM must have the “Passive” option enabled. 
A section below describes the passive presence and the ARS Monitoring ID configuration further. 

If operating RM without presence and a DDMS, a configuration utilizing passive presence is not 
required. 

4.23.1.5.3 RM and Third-Party Data Application with MNIS 

The RM application and a third-party data application may reside on the same computer if they 
both utilize the MNIS and DDMS. The radios can be programmed to send their ARS messages to 
the shared MNIS and tracked by the shared DDMS and no additional considerations are required. 
Check with the third-party data application vendor on whether they support MNIS and DDMS. 

There are many third-party data applications available for MOTOTRBO. These applications may 
utilize resources on the computer that conflicts with RM. If a conflict between a third-party data 
application and RM is discovered, or if the third-party data application vendor has requirements 
above cohabitation with other applications, the applications can be installed on different 
computers, each with their own MNIS, but they will need to share a DDMS. Both MNIS 
installations would be configured to reference one DDMS installed on one of the computers. These 
computers must be in communication via an IP network. The radios would be programmed to send 
their ARS messages to the MNIS that is on the same computer as the DDMS. The DDMS shares 
the presence and mobility with both MNISs. 

4.23.1 .5.4 Passive Presence and ARS Monitor ID Configuration 

In order for the RM to utilize the ARS on a system that has a third-party data application that also 
utilizes the ARS with control stations, a passive presence configuration must be utilized. This 
configuration essentially allows the RM to passively monitor the ARS messages sent by the radio 
to the third-party data application without interfering. The preceding “RM and Third-Party Data 
Application with MNIS” section describes when this configuration may be required. 

When using a passive presence configuration, the control stations and MNIS associated with the 
RM are programmed with an ARS Monitor ID that matches the radio ID of the third-party data 
application’s control stations. Additionally, the DDMS used by RM is configured with a “Passive” 
option. 

A control station or MNIS with an ARS Monitoring ID monitors the selected channel for ARS 
messages targeted towards the specified radio ID. When an ARS message is received, the 
message is forwarded, but is not acknowledged over-the-air. This ensures there are no over-the- 
air collisions with the acknowledgements sent by the third-party data application’s control stations. 
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Control stations and MNISs with an ARS Monitoring ID continue to transmit and receive normally 
on their own programmed radio ID and application ID. The radio IDs of the control stations or the 
application ID of the MNIS used by the RM must be different than the third-party data application’s 
control stations. 

When the DDMS is configured with the “Passive” option enabled, it continues to monitor for 
incoming ARS messages and notifies its watchers, but does not acknowledge the incoming 
messages. This ensures there are no over-the-air collisions with the acknowledgements sent by 
the third-party presence application. 

NOTE: It is important to note that not only are the RM control stations not acknowledging the 

incoming ARS messages; they are not sending negative acknowledgements or selective 
retry requests either. This means that if a message is not successfully received by the RM 
control stations, the radio is not aware of it. This limitation can be mitigated by placing the 
RM control stations in a location with similar RF conditions as the third-party data 
application control stations. 

The diagram below shows a control station passive presence configuration in a conventional 
system with a third-party data application. 
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The following diagram shows a control station passive presence configuration in a Capacity Plus 
system with data revert and a third-party data application. 

NOTE: Only the control stations used for monitoring automatic registration messages on the 
revert channels require an ARS Monitor ID. 
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Figure 4-59 RM Application with Control Stations and Passive Presence Configuration with Third-Party 
Data Application on a Capacity Plus Data Revert Configuration 
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Figure 4-60 shows a passive presence configuration in a Capacity Plus system with data revert 
where the RM is utilizing a MNIS and the third-party data application is using control stations. The 
basic operation is the same as the control station configuration shown above. 
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Figure 4-60 RM Application with MNIS and Passive Presence Configuration with Third-Party Data 
Application on a Capacity Plus Data Revert Configuration 



4.23.2 Over-the-Air Authentication Key Management 



Over-the-air programming of a radio requires the system administrator to provide an 
authentication key that matches the authentication key programmed in the radio. The provided 
authentication key must match the authentication key in the radio prior to performing the first over- 
the-air operation. This ensures that only a validated RM is communicating with a customer’s radio. 
This also ensures that RM is communicating with validated radios. 

The initial authentication key (key ID and key value) must be programmed in the radio via wired 
CPS prior to the first over-the-air operation. The authentication key is set within RM the first time 
when the archive is imported. It can also be entered manually if an archive is not available. 

The authentication key can be changed over-the-air if the current authentication key in the radio is 
known. The system administrator only needs to update the current authentication key in the RM to 
the new authentication key and deliver and switchover the configuration. The RM utilizes the 
current authentication key to authenticate the session, and then updates the radio’s authentication 
key with the new authentication key. The new authentication key becomes the current 
authentication key once successfully switched over. 

If the current authentication key in the radio is unknown, it can only be updated via wired CPS. 
Once updated, the archive should be imported into RM so that the authentication key updated in 
the radio becomes the current authentication key in RM. 
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4.23.3 Over-the-Air Privacy Key Management 

OTAP utilizes the standard data service privacy methods - enhanced and basic. It is 
recommended that privacy be enabled in the system if performing OTAP. 

The encryption/decryption is performed at the control station or MNIS and at the end radio. The 
control station and MNIS can be configured for either basic, or enhanced privacy, but not both at 
the same time. Therefore a channel must only contain radios that all have basic privacy or all have 
enhanced privacy if utilizing OTAP. 

NOTE: The control station or MNIS used for OTAP must contain all the privacy keys within all the 
radios. The radios must contain the privacy key used for transmit by the control station or 
MNIS. 

The privacy keys are used for both voice and data and can be different per radio. Since the control 
stations and MNIS communicate with many radios, they a control station must contain all keys 
utilized on the designated channel for conventional or on the system in trunking. If OTAP is utilized 
through a control station, a single conventional channel or a trunking system is limited to the 
number of enhanced privacy keys that can be contained within one control station (which is 16 
keys for enhanced privacy). Since the MNIS supports a large number of enhanced privacy keys 
(255), this limitation is not present if the MNIS is utilized. 

Additionally, all radios must contain the key the control station or MNIS is using for transmit. There 
is no specific OTAP privacy key. The key designated for the selected channel is used for 
transmitting OTAP data. 

4.23.3.1 Updating the Privacy Keys in the System 

Over-the-air programming of privacy keys is supported. They can be updated within the RM and 
delivered to the radios, just like any other parameter. Although performing a key change on a 
system requires additional considerations to be taken since the keys are also contained within the 
control stations or MNIS used to deliver the keys to the radios. 

The old and new keys must be in the control stations or MNIS if communication with the radios is 
required while transitioning. For example, if the radio registers its presence after it has switched 
over; the control station or MNIS is not able to receive the message if it does not have the new key. 
This can be resolved by either provisioning the new keys into the MNIS or control station’s receive 
list (but still transmitting on old key), or by suppressing ARS after the switchover. Keeping the old 
and new keys in the control station limits the number of usable keys in the system to half of what 
the control station can hold (16/2=8). The MNIS supports a large number of keys (255); therefore 
this limitation is not present if the MNIS is utilized. Since there is only one basic privacy key per 
radio, it is not possible to contain both the old and new basic privacy keys. 

NOTE: At minimum, the privacy keys must be updated in the control station or MNIS after 

successfully delivering all the radio’s keys over-the-air, or future over-the-air operation to 
the updated radios will not be successful. 
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In order to program the control stations connected to the device programmer, the device 
programmer can be temporarily configured via a wired connection. This option can be found in the 
settings of the device programmer. The MNIS keys can be updated through the user interface. 

Finally, since the new keys are delivered using the old keys, if it is believed that the old keys have 
been compromised, wired CPS should be used to update the keys in the radios. 

4.23.4 Performance of Over-the-Air Programming 

The performance of OTAP is commonly broken into two categories: performance in regard to time 
to complete an over-the-air operation and the impact of the over-the-air operation on other 
system services. 

4.23.4.1 Time to Complete Over-the-Air Operations 

There are three major over-the-air operations in RM: retrieval, delivery, and the switchover. The 
time it takes to perform any of these operations is highly dependent on the details of the operation 
itself and the environment of the system. 

The time to deliver or retrieve a new configuration is dependent on the following conditions: 

• size of the configuration update 

• number of radios being processed 

• system loading 

• RF environment 

Because of these numerous dependencies, it may be difficult for the system administrator to 
exactly determine the time it takes to perform an operation over-the-air. However, if some typical 
configurations and conditions are considered, then some typical times can be predicted that will 
allow the system administrator to plan their time to some level of accuracy. 

4.23.4. 1 . 1 Size of the Configuration Update 

The first thing to understand is the relationship between the amount of configuration change and 
the amount of time it takes to transfer that change. Many items can be changed within the radio 
configuration, and each type of item changed has a different impact on the amount of data that 
needs to be transferred. There is generally no need to understand the entire relationship, but 
rather to simply understand the impact of a large change and small change. 

Only the differences between the RM configuration and the radio configuration are transferred 
over-the-air. It is always recommended that a radio be read on the wire first so that only updates 
need to be transferred over-the-air. Retrieving an entire configuration over-the-air or delivering a 
completely new template to a radio over-the-air takes the largest amount of time. 

The chart below provides some guidance between the number of address book entries updated or 
added and the time it takes to deliver them to one radio in great RF conditions with no voice 
occurring on the channel or system. Great RF conditions are defined as middle of RF coverage 
and a stationary radio. 
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NOTE: Retrieval times are slightly shorter than delivery times in general, but for planning 
purposes we are only showing delivery times. 



Time to Deliver a Number of Address Book Entries to 1 Radio 
in Great RF Conditions (Middle of Coverage and Static), and 
No Voice Load, Per System Architecture 




Number of Updated Address Book Entries 



Figure 4-61 Time to Deliver a Number of Address Book Entries to One Radio 

4.23.4.1 .2 Number of Radios being Processed 

Clearly the more radios being updated, the longer the operation takes to complete. The previous 
chart shows how long a delivery to a single radio takes to complete depending on the update size. 
This value must be multiplied by the number of radios being updated. 

The chart below shows the time it takes to update numerous radios with a “typical update”. The 
following items are considered typical updates: 

• 5 text message strings updates 

• 2 privacy keys updates 

• 25 address book updates 

• 1 channel update 

• 2 scan list updates 

• 1 receive group update 
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For reference, this typical update size is equivalent to the size of around 50 address book updates 
in the above chart. As can be seen below, the overall time quickly adds up when performing 
operations on a large number of radios. 



Time to Deliver a Typical Change to a Number of Radios 
in Great RF Conditions (Middle of Coverage and Static), and 
No Voice Load, Per System Architecture 




Figure 4-62 Time to Deliver a Typical Change to a Number of Radios 

As a rule of thumb, on an idle system, in great RF conditions, around 35-45 radios can get a typical 
update in an hour. This rate may increase or decrease depending on the system architecture type. 
This of course assumes all radios are present on the channel or system when the operation is 
scheduled. If a radio is not present, the operation continues to run until the radio becomes present, 
or the operation is cancelled by the system administrator. 

4.23.4.1.3 System Loading and RF Environment 

It is always recommended to schedule over-the-air operations during times of low voice traffic and 
when the radios are stationary and in great RF coverage. However it is recognized that this is not 
always possible. 

The RM shares the channel with voice and other data services. Therefore if voice traffic loading is 
high at the time an over-the-air operation is scheduled, there is less bandwidth available for RM. 
Therefore the time to deliver increases as the RM waits for the voice to end. 

In addition, if some of the target radios are in poor RF conditions, data delivery times can be longer 
due to the need to retry any failed messages. Radios that are moving are affected more than those 
that are stationary, therefore radios that are in vehicles or carried by hand while walking 
experience longer delivery times. These conditions are always present, but become noticeable 
when sending many large data messages. 
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The chart below provides some expectations on delivery times for a typical change on a single site 
repeater channel with typical RF conditions and high voice usage. 

The bottom of the thick line is the baseline time if all radios were in great RF conditions, stationary 
and there was little voice (from the chart above). The remaining part of the line is the estimated 
amount of time with an expected distribution of RF conditions for each radio. The majority of the 
scenarios will be towards the bottom and the less likely scenarios are towards the top. 

Note that this chart does not represent the worst case scenario since it is unlikely that all radios 
are in the worst conditions. This is the expected distribution (thickness of line) for all conventional 
architectures including direct mode, single site, and IP Site Connect. See the chart above for the 
estimated baseline in great RF conditions, stationary and with little voice. 
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Figure 4-63 Time to Deliver a Typical Change to a Number of Radios in Single Site Mode 
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The chart below provides some expectations on delivery times for a typical change on a Capacity 
Plus system with typical RF conditions and high voice usage. Note this is the expected distribution 
(thickness of line) for all trunking architectures including Capacity Plus and Linked Capacity Plus. 
See the previous charts for the estimated baseline (bottom of line) in great RF conditions, 
stationary and with little voice. 




Figure 4-64 Time to Deliver a Typical Change to a Number of Radios in Capacity Plus Mode 



4.23.4.2 Performance Impact on Other Services 

Performing a RM retrieval, delivery, or switchover over-the-air can have an impact on other 
services on the channel or system. The three major impacts to consider are: 

• Voice access time during an over-the-air operation 

• Voice downtime during a switchover 

• Data downtime during a switchover 

4.23.4.2.1 Voice Access Time during an Over-the-Air Operation 

As previously mentioned, it is always recommended to schedule over-the-air operations during 
times of low voice traffic and when the radios are stationary and in great RF coverage. But it is 
recognized that this is not always possible. 

In conventional modes, it has been established that voice traffic has an impact on the time it takes 
to perform RM over-the-air operations, but these operations also have an impact on voice traffic. 
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NOTE: Radios with software versions prior to R02. 10.00 do not have access to the channel during 
an ongoing RM over-the-air operation. They most likely receives a talk prohibit tone, since 
the channel is busy processing data. All radios, regardless of software version, attempting 
confirmed private calls on a conventional channel while OTAP is occurring experience a 
low success rate. This is not just the radio being configured, but rather all radios on the 
conventional channel. To mitigate this, a pacing option can be set within the RM Device 
Programmer so that there are times of idle between each delivery or retrieval. The pacing 
duration is suggested to be greater than five minutes. 

Radios with software version R02. 10.00 and later access the channel and temporarily interrupt 
ongoing RM over-the-air operations. This interruption procedure causes an increase to voice 
access time by on average of 1.5 seconds, and worst case 3.5 seconds. While waiting for the 
procedure to complete, the radio user hears a wait tone, followed by a talk permit tone. Display 
models also provide an indication of when high volumes of data are occurring on the channel they 
are selected on. This notifies them that an update is occurring on the system and that their channel 
access may be slower than normal. This is not just the radio being configured, but rather all radios 
on the conventional channel. 

Voice access time for all radios is not affected during a RM over-the-air operation in Capacity Plus 
or Linked Capacity Plus systems as each transmission occurs on its own channel. However, the 
radio currently being configured over-the-air experiences the increase to voice access time 
described above. 

4.23.4.2.2 Voice Downtime During a Switchover 

When the radio applies a delivered configuration, the radio must reset to apply the changes. While 
resetting the radio is not be able to transmit or receive voice over-the-air. A reset after a switchover 
typically causes voice downtime for a single radio in the range of 20-22 seconds. 

If multiple radios are being switched over, and critical communication parameters are being 
updated, voice downtime occurs on the system from when the first radio starts its reset to when 
the last radio finishes its reset. During this time, there may be a mismatch in communication 
parameters across radios and therefore communication may be disrupted. 

If using a non-zero switchover timer, the voice downtime can be as long as the switchover timer 
itself since some users may choose to delay their switchover. 

When performing a delivery with switchover, each radio is switched over as the delivery occurs, 
therefore the voice downtime can be as long as it takes to deliver to all radios. See the charts in 
previous sections. 

To minimize voice downtime, it is recommended to deliver the configurations, and then schedule 
an independent switchover with a zero value switchover timer and ARS suppression enabled. 
Other deliveries or retrievals should not be scheduled to occur at the same time as a switchover. 
This may cause a delivery to occur in between the switchovers, which increases the overall 
downtime. The chart below provides some expectations on how long the voice downtime is when 
in great RF conditions and no voice load in that scenario. This assumes all radios are present. 
Note that in poor RF conditions and in the presence of voice, these times can increase. 
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Voice Downtime when Switching Over a Number of Radios 
in Great RF Conditions (Middle of Coverage and Static), and No Voice Load 




Figure 4-65 Voice Downtime when Switching Over a Number of Radios 
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4.23.4.2.3 Data Downtime During a Switchover 

When the radio applies a delivered configuration, the radio must reset to apply the changes. The 
impact on a system with a third party data application should be carefully considered. 

It is difficult to predict the impact of an over-the-air configuration on every third party data 
application in the market. It is recommended that a small scale test, with a few controlled radios, is 
run to understand the recovery process for a specific third party data application before performing 
a configuration change on a large group. 

Here are some conditions to consider: 

• If features, options, or channels required by the third party data application within the 
radio are updated incorrectly, a problem can occur. Be cautious when changing such 
options. 

• If ARS Suppression After Switchover option is selected, and the new configuration 
causes the radio to be on a different channel, then the routing of a third party data 
application that utilizes ARS may lose track of which channel the radio is on. Be careful 
to only suppress ARS after a switchover if making minor changes that do not affect the 
currently selected channel. 

• Because the radio performs a reset, temporary data could be lost. However, if the ARS 
Suppression After Switchover option was checked within RM, not only does the radio 
not send a new ARS message after reset, it also preserves all previous LRRP requests 
and text message service availability requests for this power cycle. This ensures the 
radio continues sending GPS messages, and knows where the text message server is 
located after a switchover. If LRRP is already stored persistently, then it can still be 
stored after a switchover regardless of the ARS Suppression After Switchover option. 

• If the third party data application’s temporary data is lost, then the radio may need to re- 
register after a switchover to trigger the data application to send new information. If this 
is the case then the ARS Suppression After Switchover option should be unselected, 
allowing the radio to send an ARS message after a switchover. 

• If the third party data application sends a large number of data messages to a radio 
when it registers, one should take caution when switching over many radios at the same 
time, since this could cause an influx of data messages on the channel. Consider 
increasing the radio’s ARS Initialization Delay timer on the presence registrations. Since 
this can delay sending the ARS message, it could increase the amount of time before 
the radio contacts the data application, and therefore increases data downtime. 
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4.23.5 RM Computer Specifications 



Component 


Requirements 


Operating Systems 


Windows 8 (32 & 64-bit) 


Windows 8 Pro (32 & 64-bit) 


Windows 7 Home Premium Edition (32 & 64-bit) 


Windows 7 Professional Edition (32 & 64-bit) 


Windows Vista Home Premium Edition (32 & 64-bit) 


Windows Vista Business Edition (32 & 64-bit) 


Windows XP Home/Professional Edition with SP3 & Windows Installer 3.1 (32 & 
64-bit) 


Windows Server 2008 R2 (32 & 64-bit) (for Server Installations) 


Memory 


RM Client / RM Server / RM Device Programmer Install: 1 GB and above 
required by host Operation System 


RM Server / RM Device Programmer Install: 1 GB and above required by host 
Operation System 


RM Client Only Install: RAM required by host Operation System 


Hard Disk 


RM Client / RM Server / RM Device Programmer Install: 5 GB (Program Files & 
Database) 


RM Server / RM Device Programmer Install: 5 GB (Program Files & Database) 


RM Client Only Install: 400 MB (Program Files & Archive Files*) 


* More space would be required if saving archive files of your radios and 
device update packages. Each archive file or device update package 
varies in size depending on the features of the radio. 


Other (All Installs) 


USB ports (1 or more depending on system configuration) 


Network Connection 


DVD Drive 


Software 


Running multiple instances of the RM application on one computer is not 
recommended. 


* When installing the RM Server on Windows XP, the RM Client, Job 
Processor and Device Programmer must be installed on the same 
machine. For distributed RM systems, the RM Server requires Windows 
Server 2008, Windows 7, or Windows 8. 



The MNIS and DDMS do not currently support Windows 8 or Windows Vista. 
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4.24 Configurable Timers 

The following is a list of timers that are used to synchronize communication in the radio system. 
The values of these timers can be configured through the CPS. 



Timer 

Name 


Description 


Notes 




Preamble is a string of bits added in front of a data 
message or control message (Text Messaging, Location 
Messaging, Registration, Radio Check, Private Call, etc.) 
before transmission. This preamble prolongs the message 
in order to reduce the chances of the message being 
missed by the receiving radio. The Transmit (TX) Preamble 
Duration sets the duration of the preamble. This duration 
needs to be increased as the number of scan members 
increases on the target radio (refer to the MOTOTRBO 
system planner for guidance on how to set the duration). 
This value can be increased in all the transmitting radios if 
scanning radios are often missing data messages. 
However, a larger preamble occupies the channel longer. 
Therefore, increasing the Transmit Preamble duration will 
increase the success rate of data received while other 
radios are scanning, but will decrease the amount of data 
that can be transmitted on the channel. This is a radio-wide 
feature. 


The TX Preamble 
feature is disabled if 
the duration is set to 0. 


TX Preamble 
Duration 


This feature is 
supported in Digital 
mode only. 


Talkaround 
Group Call 
Hang Time 


Sets the duration during which a radio talks back to a 
received call or continues a transmitted call using the 
previously received or previously transmitted digital Group 
ID. This hang time is used during a Group Call in 
Talkaround mode to produce smoother conversation. 
During this time, other radios can still transmit since the 
channel is essentially idle. After the hang timer expires, the 
radio transmits using the Contact Name specified for this 
channel. 


This feature is 
supported in Digital 
mode only. 


Talkaround 
Private Call 
Hang Time 


Sets the duration the radio keeps the call setup after the 
user releases the Push-to-Talk (PTT) button. This is to 
avoid setting up the call again each time the user presses 
the PTT to transmit. This hang time is used during a Private 
Call in Talkaround mode to produce smoother conversation. 
During this time, other radios can still transmit since the 
channel is essentially idle. 


- 
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Timer 

Name 


Description 


Notes 


Subscriber 

Inactivity 

Timer 


The Subscriber Inactivity Timer (SIT) controls how long the 
repeater will continue transmitting with absence of 
subscriber activity on the uplink. If the repeater is operating 
on shared-use frequencies, it cannot remain keyed 
indefinitely for the benefit of broadcasting synchronization 
signals to radios. The repeater will likely be de-keyed most 
of the time; thereby requiring radios to first activate the 
repeater (via the uplink frequency) and acquire 
synchronization (via the downlink frequency) before 
completing the call setup request and subsequent first 
transmission. The net result of these extra procedures is 
increased access time; therefore, it is desirable to avoid 
these steps, whenever possible. There is a trade-off to 
minimizing access time by keeping the repeater keyed for 
as long as practically possible, while complying with the 
regulations regarding shared-use channels, which 
essentially require the repeater to de-key when the channel 
is not in use. This can be balanced with the use of the 
Subscriber Inactivity Timer. If shared use is not a concern, 
the SIT can be set to the maximum value. If shared use is a 
concern, the SIT should be set equal to or slightly longer 
than the configured call hang timers. 


The value of this 
feature must be equal 
to or greater than the 
Hang Time (Group, 
Private or Emergency 
- whichever is the 
longest). 


This feature is disabled 
if Repeater Mode is set 
to Analog. 


Group Call 
Hang Time 


Sets the duration the repeater reserves the channel after 
the end of a Group Call transmission. During this time, only 
members of the Group that the channel is reserved for can 
transmit. This produces smoother conversation. 


This feature is disabled 
if Repeater Mode is set 
to Analog. 


The value of this 
feature must be equal 
to or less than the 
Subscriber Inactivity 
Timer value. 


Private Call 
Hang Time 


Sets the duration the repeater reserves the channel after 
the end of a Private Call transmission. During this time, only 
the individuals involved in the call that the channel is 
reserved for can transmit. This produces smoother 
conversation. The user may want to set a longer hang time 
than the Group Call Hang Time as an individual tends to 
take a longer time to reply (talkback) in a Private Call. 


This feature is disabled 
if Repeater Mode is set 
to Analog. 


The value of this 
feature must be equal 
to or less than the 
Subscriber Inactivity 
Timer value. 


Emergency 
Call Hang 
Time 


Sets the duration the repeater reserves the channel after 
the end of an Emergency Call transmission. During this 
time, only members of the Group that the channel is 
reserved for can transmit. This produces smoother 
conversation. The user may want to set the longest hang 
time as compared to the Private and Group Call Hang Time 
to reserve the channel long enough to receive an 
emergency response. 


This feature is disabled 
if Repeater Mode is set 
to Analog. 


The value of this 
feature must be equal 
to or less than the 
Subscriber Inactivity 
Timer value. 
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Timer 

Name 


Description 


Notes 


Call Hang 
Time 


Sets the duration the repeater will reserve the channel for 
after the end of an analog call transmission. During this 
time, only members of the call that the channel is reserved 
for can transmit. This produces smoother conversation. As 
this hang timer is shared among all types of analog calls 
(Group, Private, Emergency etc.), the duration should be 
set following the call type that needs the longest hang time. 


This feature is enabled 
only if Repeater Mode 
is set to Analog or 
Dynamic Mixed Mode. 


TX Interval 


The station will generate a Continuous Wave Identification 
(CWID, also called BSI) when the repeater has no other 
repeat audio requests (either analog or digital), analog or all 
digital hang time has finished and the programmed 
transmission interval timer period has expired. This feature 
should be set to a period shorter than the Mix Mode Timer 
to allow the station the opportunity to send a CWID at the 
end of a set of user radio exchanges prior to having to send 
the ID mixed with analog repeat audio. 


- 


Mix Mode 
Timer 


The station will generate a Continuous Wave Identification 
(CWID) mixed with analog audio when the repeater is 
repeating analog signals or is in analog hang time and the 
programmed mix mode timer has expired. This feature 
should be set to a period longer than the TX Interval to 


This feature is disabled 
by the repeater if the 
value is set to 255 in 
Analog mode. This 
feature is also disabled 
by the repeater if it is in 
Digital or in Dynamic 
Mixed Mode. 




allow the station the opportunity to send a CWID by itself at 
the end of a set of user radio exchanges rather than having 
to send the ID mixed with analog repeat audio. 


This feature is not 
applicable to digital 
repeater operation as 
CWID will not be 
generated while digital 
repeat is in progress. 


Pretime 


Sets the duration that the radio waits, after a Push-to-Talk 
(PTT) button press, before it starts transmitting the 
Motorola Data Communication (MDC) signaling system 
data packet (e.g. preamble bit sync) and data. When 
communicating via a repeater system or console, this 
feature allows the repeater to stabilize before the radio 
starts transmitting the data. Additionally, this timer gives 
scanning radios time to land on the channel prior to the 
reception of MDC data. 


This feature is 
supported in Analog 
mode only. 
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Timer 

Name 


Description 


Notes 


Coast 

Duration 


If the carrier signal is lost after Motorola Data 
Communication (MDC) signaling data is detected, the radio 
stays muted for the duration of this timer or until the carrier 
signal is redetected. Once the carrier signal is redetected, 
this timer is stopped, and the Data Operated Squelch 
(DOS) Auto Mute Duration timer begins again. This feature 
helps to prevent temporary loss of DOS in areas of poor 
signal strength or signal distortions. 


- 


Auto Mute 
Duration 


Sets the duration that the radio remains muted when the 
radio is receiving Motorola Data Communication (MDC) 
signaling data to reduce noise from the data reception. The 
user has to know the size of the data to select a suitable 
duration. If the duration is too short then some unwanted 
noise will still be heard, and if the duration is too long, it 
might clip some voice audio. This is normally used on 
radios that support both voice and data on the same 
channel. 


This feature is 
supported in Analog 
mode only. 


Fixed Retry 
Wait Time 


Sets the duration that the radio waits before attempting 
another polite or impolite transmission to transmit signaling 
data. Configuring the radios with different wait durations 
increases the probability of accessing the system and 
reduces the chances of data lost due to collisions. 


This feature is 
supported in Analog 
mode only. 


Time-Out 
Timer (TOT) 


The Time-Out Timer (TOT) is the amount of time that the 
radio can continuously transmit before transmission is 
automatically terminated. This feature is used to ensure the 
channel is not monopolized by any one radio. The user may 
set smaller time-outs for busier channels. This is a channel- 
wide feature. 


- 


Time-Out 
Timer Rekey 
Delay 


Sets the amount of time that the radio waits on a channel 
after the Time-Out Timer expires (which stops the radio 
transmission) before allowing the user to transmit again. 
This is a channel-wide feature. 


- 


Analog Hang 
Time 


This sets the duration of the radio that will remain on a 
landed analog channel after the end of a transmission 
during a scan operation. The hang time prevents the radio 
from resuming scanning until the conclusion of the 
response to the initial call. The timer starts after the end of a 
transmission and resets whenever a valid activity is 
detected on the channel during the hang time. 


It is recommended to 
increase the hang time 
value if the call hang 
timer in the radio 
increases for direct 
mode operation. In 
repeater mode 
operation, it is 
recommended to keep 
this value as low as 
possible to allow the 
radios to start scanning 
as soon as the existing 
analog call ends. 
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Timer 

Name 


Description 


Notes 


Digital Hang 
Time 


This sets the duration of the radio that will remain on a 
landed digital channel after the end of a transmission during 
a scan operation. The hang time prevents the radio from 
resuming scanning until the conclusion of the response to 
the initial call. The timer starts after the end of a 
transmission and resets whenever a valid activity is 
detected on the channel during the hang time. 


It is recommended to 
increase the hang time 
value if the call hang 
timer in the radio or 
repeater increases. 


Signaling Hold 
Time 


Sets the amount of time that the radio waits on an analog 
Scan List channel when a carrier signal of sufficient 
amplitude is detected on the channel. This pause allows the 
radio time to decode the analog system signaling data. If 
the decoded information is incorrect, the radio reverts to 
scan. 


This feature must be 
equal to or greater 
than the amount of 
time it takes the radio 
to transmit the 
signaling data packet 
plus the channel's 
Signaling Systems 
Pretime. 


This feature is 
supported in Analog 
mode only. 


Priority 
Sample Time 


Sets the duration that the radio waits, when in a call, before 
scanning the priority channels. If the call is taking place on 
a Priority 1 Channel, no scanning will take place. When 
scanning priority channels, the radio briefly mutes the 
current transmission. Increasing this interval improves the 
audio quality of the current transmission as fewer checks 
are done, but this also increases the chance of the radio 
missing out priority channel activity. 


A priority member must 
be present in the Scan 
List. 
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SECTION 5 SALES AND SERVICE SUPPORT TOOLS 



5.1 Purpose 

This module introduces the standard system layout, identifying each component’s role in servicing 
the system features listed in Module 2. This module is to help the reader understand what devices 

are needed to support a particular system feature. It will also display the building blocks of the 

system from a subscriber only system to a mixed mode multi-repeater, data capable system. 

5.2 Applications Overview 

The three software applications listed below, and their associated drivers are available on the CD 
kit (RVN5115J. 



Name 


Application Overview 


Customer Programming 
Software (CPS) 


CPS enables a dealer to program the device’s features according to the 
customer requirements. Navigating around the CPS is now easy and 
convenient with the addition of a help pane that displays topic-sensitive help 
instantly without the need to access the online help file. 


AirTracer 


AirTracer has the ability to capture over-the-air digital radio traffic and save 
the captured data into a file. AirTracer can also retrieve and save internal error 
logs from MOTOTRBO radios. The saved files can be analyzed by trained 
Motorola personnel to suggest improvements in system configurations or to 
help isolate problems. 


Tuner 


Tuner is an application to tune and test subscriber and repeater products. 
Navigating the around the Tuner is now easy and convenient with the addition 
of a help pane that displays topic-sensitive help instantly without the need to 
access the online help file. 
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5.3 Service Equipment 

5.3.1 Recommended Test Equipment 

The list of equipment contained in the table below includes most of the standard test equipment 
required for servicing Motorola portable radios, as well as several unique items designed 
specifically for servicing this family of radios. The Characteristics column is included so that 
equivalent equipment can be substituted; however, when no information is provided in this column, 
the specific Motorola model listed is either a unique item or no substitution is recommended. 



Description 


Characteristics 


Example 


Application 


Service Monitor 


Can be used as a 
substitute for items 
marked with an 
asterisk (*) 


Aeroflex 3920 
(www.aeroflex.com), or 
equivalent 


Frequency/deviation meter 
and signal generator for 
wide-range 
troubleshooting and 
alignment 


Digital RMS 
Multimeter* 


100 pV to 300 V 
5 Hz to 1 MHz 
10 Meg Ohm 
Impedance 


Fluke 179 or equivalent 
(www.fluke.com) 


AC/DC voltage and current 
measurements. Audio 
voltage measurements 


RF Signal 
Generator * 


100 MHz to 1 GHz 
-130 dBm to +10 dBm 
FM Modulation 0 kHz 
to 10 kHz 

Audio Frequency 100 
Hz to 10 kHz 


Agilent N5181A 
(www.agilent.com), 

Ramsey RSG1000B 
(www.ramseyelectronics.com), 
or equivalent 


Receiver measurements 


Oscilloscope * 


2 Channel 
50 MHz Bandwidth 
5 mV/div to 20 V/div 


Leader LS8050 
(www.leaderusa.com), 
Tektronix TDSIOOlb 
(www.tektronix.com), or 
equivalent 


Waveform measurements 


Power Meter 
and Sensor * 


5% Accuracy 
100 MHz to 500 MHz 
50 Watts 


Bird 43 Thruline Watt Meter 
(www.bird-electronic.com) or 
equivalent 


Transmitter power output 
measurements 


RF Millivolt 
Meter 


100 mV to 3 V RF 
10 kHz to 1 GHz 


Boonton 92EA 
(www.boonton.com) or 
equivalent 


RF level measurements 


Power Supply 


0 V to 32 V 
0 A to 20 A 


B&K Precision 1790 
(www.bkprecision.com) or 
equivalent 


Voltage supply 
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5.4 Documentation and Trainings 

5.4.1 MOTOTRBO Documentation 



The following items listed are documentation provided by Motorola to support the entire range of 
products available in the MOTOTRBO system. 



Motorola Part No. 


Name 


6880309T10 


MOTOTRBO CPS, Tuner and AirTracer Applications Installation Manual 


6880309T18 


XPR 4300 / XPR 4350 Numeric Display Mobile User Guide 


6880309T09 


XPR 4300 / XPR 4350 Numeric Display Mobile Quick Reference Guide 


6880309T15 


XPR 4500 / XPR 4550 Display Mobile User Guide 


6880309T08 


XPR 4500 / XPR 4550 Display Mobile Quick Reference Guide 


6880309T27 


XPR 6300 / XPR 6350 Non-Display Portable User Guide 


6880309T14 


XPR 6300 / XPR 6350 Non-Display Portable Quick Reference Guide 


6880309T24 


XPR 6500 / XPR 6550 Display Portable User Guide 


6880309T13 


XPR 6500 / XPR 6550 Display Portable Quick Reference Guide 


68009502001 


XPR 7550 Display Portable User Guide 


68009506001 


XPR 5350 Numeric Display Mobile User Guide 


68009504001 


XPR 5550 Display Mobile User Guide 


68009508001 


XPR 5350 / XPR 5550 Display Mobile Quick Reference Card 


68009500001 


XPR 7350 Non-Display Portable User Guide 


68009503001 


XPR 7350 / XPR 7550 Non-Display Portable Quick Reference Card 


6816814H01 


MOTOTRBO Repeater Installation Guide 


68007024098 


MOTOTRBO MTR3000 Repeater Installation Guide 


6880309T23 


MOTOTRBO Mobile Installation Guide 


6880309T21 


MOTOTRBO Mobile Basic Service Manual 


6880309T22 


MOTOTRBO Mobile Detailed Service Manual 


6880309T30 


MOTOTRBO Portable Basic Service Manual 


6880309T31 


MOTOTRBO Portable Detailed Service Manual 


68009515001 


XPR 5350 / XPR 5550 Mobile Basic Service Manual 


68009509001 


XPR 5350 / XPR 5550 Mobile Detailed Service Manual 


6880309T23 


XPR 5350 / XPR 5550 Mobile Installation Manual 


68009498001 


XPR 7350 / XPR 7550 Portable Basic Service Manual 


68009497001 


XPR 7350 / XPR 7550 Portable Detailed Service Manual 


6816810H01 


MOTOTRBO Repeater Basic Service Manual 


68007024096 


MOTOTRBO MTR3000 Repeater Basic Service Manual 
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Motorola Part No. 


Name 


6816811H01 


MOTOTRBO Repeater Detailed Service Manual 


68007024097 


MOTOTRBO MTR3000 Repeater Detailed Service Manual 


6880309T12 


MOTOTRBO System Planner 
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APPENDIX A REPLACEMENT PARTS ORDERING 



A.1 Basic Ordering Information 

When ordering replacement parts or equipment information, the complete identification number 
should be included. This applies to all components, kits, and chassis. If the component part number 
is not known, the order should include the number of the chassis or kit of which it is a part, and 
sufficient description of the desired component to identify it. 

A.2 Motorola Online 

Motorola Online users can access our online catalog at 
https://businessonline.motorolasolutions.com 

To register for online access, please call 1-800-422-4210 (for U.S. and Canada Service Centers 
only). International customers can obtain assistance at https://businessonline.motorolasolutions.com 

A.3 Mail Orders 

Mail orders are only accepted by the U.S. Federal Government Markets Division (USFGMD): 
Motorola Inc. 

7031 Columbia Gateway Drive 
3rd Floor - Order Processing 
Columbia, MD 21046 
U.S.A. 

A.4 Telephone Orders 

Radio Products and Solutions Organization* 

(United States and Canada) 

7:00 AM to 7:00 PM (Central Standard Time) 

Monday through Friday (Chicago, U.S.A.) 

1-800-422-4210 

1-847-538-8023 (United States and Canada) 

U.S. Federal Government Markets Division (USFGMD) 

1-877-873-4668 

8:30 AM to 5:00 PM (Eastern Standard Time) 

A.5 Fax Orders 

Radio Products and Solutions Organization* 

(United States and Canada) 

1-800-622-6210 
1-847-576-3023 (International) 

USFGMD 

(Federal Government Orders) 

1-800-526-8641 (For Parts and Equipment Purchase Orders) 

A.6 Parts Identification 

Radio Products and Solutions Organization* 

(United States and Canada) 

1-800-422-4210 
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A.7 Product Customer Service 

Radio Products and Solutions Organization (United States and Canada) 

1-800-927-2744 

* The Radio Products and Solutions Organization (RPSO) was formerly known as the Radio 
Products Services Division (RPSD) and/or the Accessories and Aftermarket Division (AAD). 





Control Station Installation 



B-1 



APPENDIX B CONTROL STATION INSTALLATION 



The Data Revert Channel concept may require careful planning to achieve the expected data 
message throughput, as described in the loading sections of the System Planner. This is especially 
true as the number of control stations in a location is increased to support larger data traffic loads. 
Poorly designed installations may result in self-inflicted interference. The end result of this 
interference is often corrupted data messages, which increases the number of data message retries. 
This increase results in an additional load placed on the system. 

B.1 Data Bearer Service 

MOTOTRBO radios support both Unconfirmed and Confirmed data bearer services at Layer 2. The 
method selected impacts the transmit and receive roles that Revert Control Stations and either 
primary control stations (conventional) or trunked control stations (Capacity Plus) play within a 
system. In turn, these roles can impact the installation. It should be noted that applications often 
implement their own confirmations at the application level (Layer 7); therefore the use of the 
Unconfirmed data bearer service does not require that messages are unconfirmed by the receiving 
radio. 

B.1.1 Unconfirmed Data 

When Unconfirmed data is transmitted, it is transmitted to the receiver once. The receiver checks the 
integrity of the entire data message (CRC check) and either passes this up to the application (CRC 
check passes) through the IP layer or discards the data (CRC check fails). Below is an example to 
highlight the roles played by the control stations. 

For example, a text message is sent from a text message server to an individual radio in a Capacity 
Plus system. Here, the text message is routed from the server to a Trunked Control Station. When 
the control station is allowed to transmit the data on the Rest Channel, it is transmitted once. The 
receiving radio then checks the integrity of the message and if the CRC check passes, the data is 
passed up to the application. Upon receipt of the text message, the radio’s application is required to 
send an application layer acknowledgement to the server for confirmation. Here, the radio moves to 
a Data Revert Channel and when allowed, transmits the data once to a Revert Control Station. The 
receiving control station checks the integrity of the message and if the CRC check passes, the data 
is passed up to the application. If the confirmation is not received by the application on the server, it 
will attempt to retry the message with the same procedure. Therefore, the use of the Unconfirmed 
Data Bearer Service can be utilized with application layer acknowledgements to provide an end-to- 
end confirmed data process. 

Below is a summary of the transmit and receive roles required of the various control stations in the 
system utilizing Unconfirmed data. 

• Revert Control Station (Conventional and Capacity Plus) - RX Only 

• Primary Control Station (Conventional) - TX Only 

• Trunked Control Station (Capacity Plus) - TX Only 

NOTE: When operating with Unconfirmed data, the Revert Control Stations may be configured to 
operate as RX Only. 
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B.1.2 Confirmed Data 

When Confirmed data is transmitted, it is transmitted to the receiver up to three times. The receiver 
checks the integrity of each TDMA burst (CRC check) as well as the entire data message (CRC 
check) and either passes this up to the application (CRC check passes) through the IP layer or 
responds to the initiating radio that select bursts or the entire message must be resent. Since 
scenarios like retries do not change the TX/RX roles played by the control stations, a first attempt 
success example is described below. 

For example, a text message is sent from a text message server to an individual radio in a Capacity 
Plus system. Here, the text message is routed from the server to a Trunked Control Station. When 
the control station is allowed to transmit the data on the Rest Channel, it is transmitted. The receiving 
radio checks the integrity of the bursts and of the message. If the CRC check passes, it transmits a 
received confirmation burst back to the Trunked Control Station as well as passes the data up to the 
application. Upon receipt of the text message, the radio’s application is required to send an 
application layer acknowledgement to the server for confirmation. Here, the radio moves to a Data 
Revert Channel and transmits the data to a Revert Control Station when allowed. The receiving 
control station checks the integrity of the bursts and of the message and if the CRC check passes, it 
transmits a received confirmation burst back to the radio as well as passes the data up to the 
application. 

Below is a summary of the transmit and receive roles required of the various control stations in the 
system utilizing Confirmed data. 

• Revert Control Station (Conventional and Capacity Plus) - RX and TX 

• Primary Control Station (Conventional) - TX and RX 

• Trunked Control Station (Capacity Plus) - TX and RX 

NOTE: When operating with Confirmed data, the Revert Control Stations cannot be configured to 
operate as RX Only. 

B.2 Interference 

With multiple control stations operating in close proximity, it is important to isolate the transmitted 
signals from the receivers. Typical types of interference to consider are Intermodulation and 
Desense (Blocking). 

B.2.1 Intermodulation 

Intermodulation (IM) occurs when two or more off channel signals “mix” in the receiver’s front-end to 
create a product that falls on the receive channel. This product effectively raises the noise floor of the 
receiver and dictates a larger received signal to establish an acceptable Signal to Noise Ratio (SNR). 
Typical IM protection of the control station is around 75 dB. It should be noted that this protection 
diminishes when one of the interferes is on the adjacent channel. Operating with self-inflicted IM 
due to frequency selection is not recommended as TX/RX isolations in excess of 80 dB (depends on 
interferer level and receiver level) may be required. Adequate frequency planning/selection may 
resolve this concern. 

B.2.2 Desense (Blocking) 

Desense or blocking occurs when a very strong off-channel signal begins to saturate the receiver’s 
front end. This effectively raises the noise floor of the receiver and dictates a larger received signal to 
establish an acceptable SNR. Typical desense protection of a control station is 100 dB. Every 
installation will need to take this into consideration when designing the site installation. 
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B.3 Control Station Installation Considerations 

Mitigation techniques require isolating the transmitted signal from the receivers. Two general rules 
for good design are: 

• Place the receiving control station antennas in a location where they will receive a strong RF 
signal from the source. 

• Turn down the output power of the transmitting control stations to the minimum required power 
to establish reliable communications. 

A strong receive signal can overcome elevated noise floors without impacting data reliability and 
turning down the TX power decreases the interfering signals that the receivers must tolerate. These 
generals rules have only one objective, which is to help achieve acceptable TX/RX isolation within a 
reasonable budget. However, it should be noted that a stronger receive signal is not always better 
when IM issues exist. When the issue is caused by third order IM, every one dB of receive path loss 
will degrade the receivers’ sensitivity by one dB and improve IM performance by three dB. Two 
examples are provided to illustrate this point when IM is not an issue. 

Example 1: Fifty watts (+47 dBm) of control station output power is required, and the typical 

receiver power level into the control station is -115 dBm. The difference between the TX and the RX 
power is 162 dB. Since the control station typically provides 100 dB of blocking protection, 62 dB of 
TX/RX isolation is required. 

Example 2: Two watts (+33 dBm) of control station output power is required, and the typical 

receiver power level into the control station is -95 dBm. The difference between the TX and the RX 
power is 128 dB. Since the control station typically provides 100 dB of blocking protection, 28 dB of 
TX/RX isolation is required. This comparatively, is much easier to obtain than in Example 1. 

B.3.1 Unconfirmed Data Considerations 

The Revert Control Stations only receive and never transmit. Therefore, there are no isolation 
requirements between these stations. The installation could be as simple as using an individual 
antenna for each control station. 

The Primary or Trunked Control Stations only transmit and never receive. Therefore, there are no 
isolation requirements between these stations. The installation could be as simple as using an 
individual antenna for each control station. 

However, the Revert and either the Primary or Trunked Control Stations may be in close proximity 
with each other and there are isolation requirements between these different types of control 
stations. Assuming an IM free frequency plan was selected, the interference to account for is 
blocking. If the different types of control stations must be in close proximity, consider adding an RX 
bandpass filter to attenuate the TX signals. If an IM free frequency plan is not possible, it is 
recommended to place circulators on the transmitting control stations in order to minimize TX IM. An 
example of this type of installation is illustrated below. 
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Figure B-1 Installation of Control Stations for Unconfirmed Data 
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B.3.2 Confirmed Data Considerations 

All control stations must be both TX and RX. Therefore, there are isolation requirements between all 
control stations and not just different types of control stations. Assuming an IM free frequency plan 
was selected, the interference to design around is blocking. One method is to separate the RX and 
TX paths of the Revert Control Stations. As these are fixed frequencies, this can be accomplished 
with a duplexer. 

Trunked Control Stations are required to operate on multiple channels and Revert Control Stations 
are only required to operate on one channel; the properties of the duplexers may differ for the 
different control station types. The same techniques that were applied to Unconfirmed Data can then 
be applied to Confirmed Data. An example of this type of installation is illustrated below. 




Figure B-2 Installation of Control Stations for Confirmed Data 
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B.3.3 Antenna Separation 

One method to provide isolation between the transmitters and the receivers is through antenna 
separation. The following charts indicate the typical isolation of two dipole antennas when either 
separated horizontally or vertically. 



Horizontal Separation Isolation 
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Figure B-3 Horizontal Separation Isolation 
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Figure B-4 Vertical Separation Isolation 



Glossary 



This glossary contains an alphabetical listing of acronyms that are applicable to MOTOTRBO 
systems and products. 



Acronym 


Definition 


APP 


Analog Phone Patch 


ARS 


Automatic Registration Services 


BW 


Bandwidth 


CAI 


Common Air Interface ID 


COTS 


Commercial Off-the-Shelf 


CPS 


Customer Programming Software 


CTL 


Channel Timing Leader 


CWID 


Continuous Wave Identification (CWID) 


DCDM 


Dual Capacity Direct Mode (DCDM) 


DDMS 


MOTOTRBO Device Discovery and Mobility Service 


DMM 


Dynamic Mixed Mode 


DTC 


Designated Transmit Channel 


DTP 


Digital Telephone Patch 


DTMF 


Dual Tone Multi Frequency 


ECA 


Enhanced Channel Access 


GUI 


Graphical User Interface 


IPSC 


IP Site Connect 


ISP 


Internet Service Provider 


LAC 


Local Area Channel 


LAN 


Local Area Network 


LCP 


Linked Capacity Plus 


MCDD 


Multi-Channel Device Driver 


MNIS 


MOTOTRBO Network Interface Service 


NAT 


Network Address Translation 


NIST 


National Institute of Standard and Technology 


OB 


Option Board 



OTA 



Over-the-Air 
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Acronym Definition 



OTAP 


Over-the-Air Programming 


PBX 


Private Branch Exchange 


PN 


Presence Notifier 


PSTN 


Public Switched Telephone Network 


PTT 


Push-to-Talk button 


QoS 


Quality of Service 


RAS 


Restricted Access to System 


RDAC 


Repeater Diagnostics and Control (RDAC) 


RM 


Radio Management 


RF 


Radio Frequency 


SQE 


Signal Quality Estimation 


TOT 


Time-out Timer 


VPN 


Virtual Private Network 


WAC 


Wide Area Channel 


WAN 


Wide Area Network 
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